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The  purpose  of  this  document  is  to  summarize  the  discussions  and  conclusions  of 
a  conference  held  at  the  National  Institute  of  Standards  and  Technology  (NIST)  in  Janu¬ 
ary  1991.  The  goal  of  the  conference  was  to  examine  issues  related  to  frameworks  for 
Software  Engineering  Environments  (SEEs),  particularly  potential  convergence  between 
different  approaches  for  these  frameworks. 

The  intended  readers  of  this  document  are  persons  who  are  familiar  with  current 
trends  in  SEE  frameworks,  as  well  as  with  the  critical  issues  related  to  Entity-Relation- 
Attribute  (ERA)  and  Object-Oriented  (0-0)  object  management  systems.  Although  a 
brief  background  section  summarizes  many  of  these  issues,  this  document  will  not  serve 
as  an  introductory  primer  on  these  topics. 

The  preparation  of  these  materials  for  publication  was  done  by  David  Carney  of 
the  Institute  for  Defense  Analyses  (IDA).  The  conference  chairman,  Frank  Belz  of 
TRW,  made  significant  improvements  to  the  summary  of  the  conference  discussions,  and 
also  was  the  author  of  the  conference  Charter,  much  of  which  was  abstracted  into  Section 
3,  “Background.”  In  addition,  Patricia  Oberndorf  of  the  Naval  Air  Development  Center 
made  valuable  contributions  to  the  fiinal  form  of  his  document. 

This  paper  was  reviewed  by  the  following  members  of  IDA:  Dr.  Brian  S.  Cohen, 
Dr.  Richard  J.  Ivanetich,  Mr.  Clyde  G.  Roby,  Mr.  David  A.  Wheeler,  and  Dr.  Robert  I. 
Winner. 
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1.  INTRODUCTION 

On  January  22-23, 1991,  a  meeting  was  held  at  NIST,  in  Gaithersburg,  Maryland, 
under  the  sponsorship  of  the  Software  Technology  for  Adaptable,  Reliable  Systems 
(STARS)  program  of  the  Defense  Advanced  Research  Projects  Agency  (DARPA).  The 
meeting  was  convened  as  a  result  of  a  joint  planning  activity  in  the  fall  of  1990,  when 
representatives  of  the  STARS  Prime  contractors  and  the  STARS  Program  office  agreed 
that  the  program  would  begin  selecting  its  standards  in  early  1991 .  These  standards  will 
be  used  in  three  prototype  SEEs  that  are  being  integrated  by  the  STARS  Primes.  The  out¬ 
standing  issue  for  the  program  is  the  degree  either  of  compatibility  or  variance  between 
several  of  the  standards  under  consideration.  At  the  very  least,  there  is  an  apparent 
divergence  between  some  candidate  standards  that  may  be  critical  to  the  STARS  goal  of 
an  open  architecture  framework  across  the  three  Primes. 

The  purpose  of  the  meeting  was  therefore  to  establish  whether  it  is  technically 
feasible,  within  the  STARS  timeframe  of  1991-1993,  to  converge  existing,  apparently 
competing,  approaches  to  SEE  frameworks  as  reflected  in  certain  proposed  interface 
standards.  Such  convergence,  if  technically  feasible,  could  improve  the  prospects  for 
marketplace  acceptance  of  these  approaches,  and  thereby  speed  the  process  of  develop¬ 
ing  SEEs,  especially  including  STARS  SEEs.  Central  to  the  question  of  such  convergence 
was  the  matter  of  how  those  frameworks  standards  that  are  either  ERA  frameworks  and 
0-0  frameworks  could  interrelate,  either  within  or  between  instances  of  a  STARS  SEE. 

Attendees 

Participants  in  this  meeting  included  representatives  of  government,  commercial 
application  and  environment  developers,  and  Department  of  Defense  (DoD)  contrac¬ 
tors.  The  following  persons  were  in  attendance: 

Administrative: 

Frank  Belz,  TRW,  Chair 

David  Carney,  Institute  for  Defense  Analyses,  Recorder 
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STARS: 


Ed  Cuoco,  Digital  Equipment  Corporation  (DEC) 

David  Goiffon,  Unisys 
Bob  Ekman,  IBM/Gaithersburg 
William  Hodges,  Boeing 
Mansour  Kavianpour,  IBM/Toronto 
John  Kramer,  DARPA/STARS 
Bob  Munck,  Unisys/Reston 

Other  attendees: 

Robert  Balzer,  USC/ISI 

Hugh  Beyer,  DEC 

Eric  Black,  Atherton  Technology 

Currie  Colket,  Ada  Joint  Program  Office 

Herman  Fischer,  Mark  V  Systems 

Regis  Minot,  GIE  Emeraude 

Patricia  Oberndorf,  Naval  Air  Development  Center 

Gary  Pritchett,  SofTech/San  Diego 

Andres  Rudmik,  Software  Productivity  Solutions,  Inc. 

Ian  Thomas,  Hewlett-Packard 
William  Wong,  NIST 

Chris  Nolan,  DEC/ Varese,  Italy,  was  also  invited  to  attend  the  Conference  but 
was  unable  to  attend. 

[At  the  start  of  the  meeting,  each  participant  gave  a  brief  self-introduction,  with  a 
brief  history  of  relevant  personal  activities,  which  are  summarized  in  Appendix  B.J 

The  contents  of  the  document  include  Section  2,  a  brief  introductory  section  that 
describes  the  technical  issues  of  the  conference;  Section  3,  a  description  of  the  immediate 
background  of  the  conference;  Section  4,  a  summary  of  the  conference  discussions;  Sec¬ 
tion  5,  which  details  the  conclusions,  actions,  and  agreements  of  the  conference;  and 
several  appendices  that  include  the  minutes  of  the  conference  as  well  as  a  transcript  of 
the  summary  statement  made  by  the  conference  chairman. 
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2.  BACKGROUND 


Several  efforts  currently  specifying,  designing,  and/or  implementing  SEEs  or 
SEE  frameworks  are  also  proposing  standards  for  tool  interfaces  and  object  management 
services.  These  efforts  often  have  overlapping  goals,  and  as  a  consequence,  have  pro¬ 
posed  standards  that  appear  to  be  in  conflict.  Numerous  attempts  to  evaluate  the  current 
developments  and  future  trends  in  such  interfaces  have  been  conducted  in  recent  years 
and  are  continuing.  Interactions  among  developers  and  evaluators  have  surfaced  an 
emerging  hypothesis  that  some  approaches,  previously  considered  essentially  in  conflict, 
may  in  fact  be  complementary.  Consequently,  it  may  be  p  ssible  to  develop  standards 
that  are  “convergent”  rather  than  competitive,  in  that  they  operate  in  conjunction  with 
each  other  or  may  be  merged  into  single  standards  encompassing  and  replacing  the  com¬ 
plementary  standards. 

Currently,  numerous  framework  standards  are  competing  for  acceptance,  none  of 
which  addresses  satisfactorily  all  the  problems  facing  environment  and  tool  developers. 
This  situation  makes  it  extremely  difficult  for  tool  developers  to  determine  which  plat¬ 
forms  are  worthy  of  (re)hosting  their  tools.  Consequently,  it  is  difficult  for  framework 
developers  to  demonstrate  the  efficacy  of  their  approach  with  respect  to  existing  tools. 
The  causes  of  this  situation  are  self-perpetuating — it  takes  so  long  to  demonstrate  ade¬ 
quacy  of  new  frameworks  that  alternate  approaches  arise  £md  undercut  the  motivation  to 
commit  to  the  original  frameworks. 

Successful  convergence  would  result  in  the  simultaneous  satisfaction  of  a  broader 
range  of  tool  and  environment  developer  needs  than  can  be  satisfied  by  the  contributory 
standards  individually,  and  thereby  would  broaden  the  applicability  of  the  contributory 
standards.  This  in  turn,  could  clarify  the  marketplace  opportunities  for  tool  developers, 
and  provide  growth  paths  for  framework  and  environment  developers.  For  these  results 
to  occur,  it  will  be  necessary  to  establish  satisfactory  understanding  of  the  relationship 
between  the  convergent  standards  and  the  architectures  of  conforming  environments. 
Determining  that  there  exist  viable  architectures  that  gain  the  benefits  promised  by  con¬ 
vergence  is  one  of  the  major  technical  tasks  in  a  convergence  effort. 
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3.  SUMMARY  OF  THE  CONFERENCE  DISCUSSIONS 


The  fundamental  problem  of  frameworks  convergence  is  one  of  providing  multi¬ 
ple  interfaces  that  can  access  a  common  repository.  K  one  interface  is  0-0  in  nature  and 
another  interface  is  ERA  in  nature,  there  is  a  question  as  to  whether  and  how  much  com¬ 
monality  can  be  achieved.  The  principal  topics  for  the  Conference  were  therefore  possi¬ 
bilities  and  strategies  for  achieving  convergence  between  these  two  types  of  interface. 

3.1  Focus  of  the  Convergence  Effort 

There  are  several  efforts  currently  underway  that  use  one  of  these  interface  types. 
Among  the  most  significant  are  the  Portable  Common  Tool  Environment  (PCTE,  based 
on  an  ERA  model),  the  Common  Ada  Programming  Support  Environment  Interface  Set, 
Revision  A  (CAIS-A,  also  based  on  an  ERA  model),  A  Tool  Integration  Standard 
(ATIS,  based  on  an  0-0  model),  and  a  new  initiative  called  the  Portable  Common  Inter¬ 
face  Set  (PCIS)  which  originated  as  an  attempt  to  bridge  the  differences  between  PCTE 
and  CAIS-  A.  Of  these,  PCTE  and  ATIS  have  received  significant  attention  in  the  com¬ 
mercial  sphere,  and  were  the  two  interface  efforts  that  were  discussed  most  during  the 
conference.  Several  attempts  have  been  made  to  converge  these  two  interfaces. 

One  initial  question  for  the  conference  was  whether  a  convergence  exercise 
focusing  mainly  on  PCTE  and  ATIS  is  appropriate.  In  other  words,  convergence  between 
ERA  and  0-0  strategies  in  general  is  not  synonymous  with  convergence  between  PCTE 
and  ATIS  as  representatives  of  those  strategies.  Almost  without  exception,  for  instance, 
any  statement  made  about  convergence  that  uses  “PCTE”  could  be  recast  using  “CAIS”, 
and  the  statement  would  prove  equally  accurate.  In  the  same  manner,  although  the  PCIS 
effort  is  still  in  its  formative  stages,  it  may  result  in  a  standard  that  is  an  evolut  on  of 
current  ERA  technology.  Discussion  of  convergence  strategies  should  possib’y  be 
widened  to  include  this  effort.  Even  further,  it  could  be  argued  that  frameworks  conver¬ 
gence  should  not  be  restricted  only  to  ERA  and  0-0  notions:  conceivably  convergence 
should  embrace  items  such  as  the  UNIX  file  system  as  well. 

During  the  Conference,  however,  the  statements  of  most  participants  implied  that 
the  convergence  exercise  is  intimately  related  to  the  current  situation  in  the  CASE  com¬ 
munity,  wherein  the  only  commercially  viable  ERA  solution  is  PCTE.  Thus  for  STARS, 
an  ERA  convergence  exercise  is  basically  a  PCTE  convergence  exercise.  Similarly, 
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though  much  work  is  being  done  in  Object-Oriented  technology,  AXIS  is  the  0-0  effort 
that  has  gained  the  most  commercial  momentum  at  the  present  time.  STARS  will  observe 
and  support  the  ongoing  PCIS  effort,  since  that  is  potentially  a  vehicle  for  frameworks 
convergence.  It  is  unlikely,  however,  that  a  PCIS  implementation  will  be  in  existence 
within  the  STARS  timeframe. 

3.2  High-Level  Approaches  to  Convergence 

The  Conference  first  examined  four  high-level  approaches  in  converging  PCTE 
and  ATIS:  a  dual  interface  approach,  a  central  interface  approach,  an  approach  with 
multiple  levels  of  interface  (called  the  “wedding  cake”  approach),  and  an  approach  that 
relies  on  logically  common  infrastructure. 

3.2.1  Dual  Interface  Approach 

The  basis  for  this  section  was  Hugh  Beyer’s  report  on  the  activities  of  the  DEC 
group  at  Varese,  Italy.  Their  approach  amounts  to  building  a  database  on  one  type,  and 
providing  a  mapping  to  interfaces  of  the  other  type.  The  DEC  group  tried  this  by  building 
an  object-oriented  database,  and  then  constructing  a  set  of  ATIS  interfaces  and  a  set  of 
PCTE  interfaces  (actually  subsets  of  ATIS  and  PCTE  respectively)  on  top  of  it.  The 
PCTE  interface  implementation  was  in  terms  of  method  dispatches  driven  by  the  0-0 
database;  in  order  to  do  this,  however,  the  underlying  model  needed  semantics  that  were 
not  available  in  ATIS  (see  Figure  1).  This  experiment  demonstrated,  to  DEC’s  satisfac¬ 
tion,  that  PCTE  and  ATIS  could  share  the  same  object  base. 

It  is  also  possible  to  reverse  this  approach  and  to  build  over  an  ERA  database 
(see  Figure  2).  The  DECA^arese  group  began  their  exercise  by  trying  to  use  this 
approach,  but  they  could  not  achieve  a  workable  solution.  They  concluded  that  the  under¬ 
lying  repository  needs  to  be  an  0-0,  and  not  an  ERA  base. 

3.2.2  Central  Repository  Approach 

The  ba.sis  for  this  section  was  David  Goiffon’s  report  on  current  activities  at 
Unisys.  In  order  to  determine  whether  PCTE,  ATIS  or  some  other  framework  would  be 
an  appropriate  basis  for  repository  services  for  Unisys  tool  capabilities,  a  Unisys  team  set 
about  to  define  a  central  interface  that  satisfied  the  needs  of  those  capabilities,  and  then 
posed  the  question,  "Which  of  these  platforms  is  adequate  to  implement  the  central  inter¬ 
face?”  (See  Figure  3.) 
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Figure  1.  Dual  Interface  Model  on  0-0 


Figure  2.  Dual  Interface  Model  on  ER 

The  specific  services  required  at  the  central  interface  were  determined  on  the 
basis  of  scenarios  derived  from  the  usage  of  three  different  kinds  of  customers:  3GL  users 
(oldest,  most  sizable  customers),  4GL  users  (largest  number  of  customers),  and  Object- 
oriented  language  users  (target  customers  to  be  served  by  future  Unisys  tools).  The  team’s 
conclusion  was  that  the  facilities  required  at  the  central  interface  could  not  be  supplied  by 
either  PCTE  or  ATIS  alone. 
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Figure  3.  Central  Repository  Model 

3.2.3  “Wedding-Cake”  Approach 

The  basis  for  this  section  was  a  report  by  Regis  Minot,  from  GIE  Emeraude  A 
different  approach  is  to  present  numerous  levels  of  different  interfaces.  In  this  approach, 
tools  may  have  access  to  various  levels  as  necessary  to  be  integrated  into  the  system  (see 
Figure  4). 

Thus,  “foreign”  tools  (e.g.,  tools  that  are  neither  PCTE  nor  ATIS)  could  reside 
on  a  visible  POSIX  interface,  PCTE-only  tools  on  a  PCTE  interface,  ATIS  tools  on  a  set 
of  object-oriented  common  services,  and  some  tools  could  conceivably  require  both  0-0 
services  as  well  as  ERA  services.  It  should  be  noted  that  one  element  of  this  version, 
where  ATIS  tools  reside  on  a  set  of  conunon  services,  is  essentially  a  thing  that  the 
DEC/Varese  team  tried  unsuccessfully. 

In  this  approach,  there  is  minimal  support  for  interoperation  of  tools.  Among  the 
missing  necessities  for  tool  interoperation  are  shared  logical  schemata,  which  can  be 
expressed  either  in  a  class  hierarchy,  or  in  an  ERA  model.  Some  such  schema  is  needed. 
Thus,  while  this  approach  leads  to  putting  different  tools  into  the  same  system,  it  does  not 
go  very  far  toward  achieving  interoperation. 
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Figure  4.  ‘Wedding  Cake’ Model 

3.2.4  Logically  Common  In&^structure  Approach 

The  basis  for  this  section  was  a  presentation  by  Andres  Rudmik  of  the  CIS  Con¬ 
sortium  This  approach  differs  from  the  prior  ones  in  that  it  focusses  upon  matters  of  pol¬ 
icy.  It  is  also  based  on  the  observation  that  there  is  a  disparity  in  the  degree  to  which  cer¬ 
tain  policy  issues  have  been  addressed  in  the  underlying  infrastructure  of  ATIS  and 
PCTE.  Such  infrastucture  elements  include  mechanisms  realizing  notions  of  process  and 
transactions,  versions  and  configurations,  security,  access  controls,  and  views. 

The  approach  is  to  determine  abstract  descriptions  or  models  of  policy  and 
mechanism  in  order  to  realize,  for  example,  versioning  support,  and  to  use  these  as  the 
basis  for  achieving  logically  common  infrastructure  in  the  tools.  This  common  infrastruc¬ 
ture  is  made  real  by  being  mapped  to  the  different  mechanisms  provided  by  the 
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alternative  platforms  (see  Figure  5). 


Version  Model 


Class  hierarchy 
Method  dispath 


Figure  5.  Common  Infrastructure  Model 

This  approach  may  be  especially  helpful  in  those  areas  where  the  ATIS  specifica¬ 
tion  is  incomplete  with  respect  to  mechanisms  to  support  such  infrastructiue.  The 
approach  may  provide  guidance  on  how  to  define  the  missing  AITS  mechanisms.  Or 
where  alternative,  incompatible  mechanisms  exist  for  PCTE  and  ATIS,  it  may  assist  in 
the  definition  of  alternate  class  hierarchies  in  the  ATIS  model  to  support  the  realization  of 
such  common  infrastructures. 

3.3  Brainstorming  Exercise  On  Critical  Issues  In  Frameworks  Convergence 

A  major  goal  of  the  Conference  was  to  determine  specific  strategies,  both  short- 
and  long-term,  that  might  facilitate  frameworks  convergence.  To  that  end,  a  ‘brainstorm¬ 
ing’  exercise  was  conducted  in  which  the  participants  each  suggested  ideas,  either  in  the 
form  of  goals,  strategies,  or  merely  statements  of  fact,  believed  to  be  key  issues  related  to 
the  problem  of  achieving  convergence.  The  goal  of  this  exercise  was  to  identify  consensus 
on  which  issues  were  most  critical. 

The  output  of  the  brainstorming  was  a  list  of  45  items.  Some  were  in  the  nature  of 
statements,  others  were  possible  strategies  for  convergence.  As  these  were  discussed  and 
compared,  it  was  immediately  obvious  that  there  existed  a  wide  spectrum  of  focus  and 
scope  among  them.  The  participants  noted  that  this  made  comparing  suggestions  diffi¬ 
cult,  but  also  that  comparing  “different-in-kind”  issues  was  inevitable,  given  the  nature  of 
the  problem  and  the  needs  of  the  STARS  program.  The  participants  did  determine,  how¬ 
ever,  that  the  suggestions  tended  to  fall  into  four  broad  (sometimes  overlapping) 
categories. 


1.  Framework  requirements 

2.  Technical  approaches,  including  whether  monolithic  standards  or  fragmented  sub¬ 
sets  of  standards  are  preferable 

3.  Management  approaches  to  frameworks  standards  development 

4.  Definition  oi  the  market  place,  i.e.,  “Who  is  it  that  is  influenced  by  the  conver¬ 
gence,  and  hew  does  that  influence  matter  in  the  convergence  process?” 

3.3.1  Refinement  of  Technical  Issues 

In  order  to  refine  this  large  list,  complementary  items  were  merged.  Then,  to  dis¬ 
cover  whether  the  Conference  as  a  whole  had  any  shared  sense  of  priorities,  a  vote  was 
taken  on  the  criticality  of  each  item.  The  results  of  this  process  indicated  a  general  agree¬ 
ment  that  out  of  the  original  45,  four  key  issues  were  most  significant.  In  the  order  of 
priority,  the  issues  are  as  follows; 

1.  0-0  capabilities  with  PCTE 

2.  Useful  union  of  existing  standards 

3.  Know  the  intended  beneficiaries  of  convergence 

4.  Approaches  to  logical  schema 

Of  these,  the  first  two  fall  under  the  “Technical  Approach”  category,  the  third  in 
the  “Target  Market”  category,  and  the  fourth  was  considered  to  be  in  both  the  “Technical 
Approach”  and  the  “Framework  Requirements”  categories.  In  the  voting  on  criticality  of 
these  four  issues,  the  first  (0-0  capabilities  with  PCTE)  was  chosen  by  a  wide  margin  as 
the  most  important.  The  other  three  were  considered  to  be  approximately  equal  in  criti¬ 
cality.  No  issue  in  the  “Management  approaches”  category  received  a  large  number  of 
votes. 


3.3. 1.1  0-0  Capabilities  with  PCTE 

This  key  issue  is  a  merger  of  three  slightly  different  suggestions: 

1.  “Given  that  PCTE  is  standardized  and  ATIS  is  in  a  formative  stage,  start  with  PCTE 
interface  and  find  a  new  object-oriented  view  that  has  PCTE  in  mind  (instead  of  the 
object-oriented  view  that  has  UNIX  in  mind,  like  ATIS  is).” 

2.  “Design  an  object-oriented  layer  that  is  a  common  service  on  top  of  ECMA/PCTE.  It 
should  satisfy  object-oriented  requirements  that  have  been  identified  for  these  systems  (in 
particular  ATIS  and  PCIS).” 
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3.  “Develop  object-oriented  interface  support  services  on  top  of  PCTE  which  both  com¬ 
plements  PCTE  and  has  no  unnecessary  changes  to  AXIS.” 

These  three  items  indicated  a  widespread  desire  to  explore  the  relationship 
between  0-0  mechanisms  and  the  PCTE  mechanism.  The  precise  nature  of  the  relation¬ 
ship,  whether  simple  coexistence  or  a  predominance  of  one  view  over  another,  remains  to 
be  seen. 

3.3.1.2  Useful  Union  of  Existing  Standards 

This  key  issue  was  a  merger  of  two  other  suggestions: 

1.  “Achieve  frameworks  convergence  by  defining  the  ‘useful  union’  of  CAIS,  PCTE, 
ATIS  (and  perhaps  other  frameworks).  ‘Useful  union’  is  defined  as  taking  the  intersec¬ 
tion  of  the  existing  standards,  then  adding  in  some  desirable  features  that  now  exist  in 
some  of  them.” 

2.  “Don’t  feel  compelled  to  take  various  standards  in  their  entirety;  it  is  possible  to  take  a 
meaningful  necessary  subset.” 

This  suggestion  is  targeted  at  finding  the  minimum  necessary  means  to  achieve  the 
required  capabilities  of  converged  interfaces. 

3.3.2  Know  the  intended  beneficiaries  of  convergence 

This  key  issue  was  the  result  of  five  suggestions: 

1.  “Exploit  the  fact  that  tool-writers  (not  tool-users)  are  the  marketplace  for  (benefi¬ 
ciaries  of)  convergence.” 

2.  “Exploit  the  fact  that  tool-users  (not  tool-writers)  are  the  marketplace  for  (benefi¬ 
ciaries  of)  convergence.” 

3.  “Resolve  the  question:  Who  are  we  trying  to  satisfy?” 

4.  “Exploit  the  concept  that  the  ultimate  benefactors  of  frameworks  convergence  are 
application  developers.” 

5.  “Understand  if  and  how  0-0  database  vendors  have  a  place  in  the  result  of  this 
process.” 

Some  of  these  are  contraxiictory;  in  particular,  the  first  and  second  items  in  the 
above  list.  What  is  true  about  all  of  these  statements,  however,  is  that  they  suggest  that 
the  beneficiaries  of  frameworks  convergence  need  to  be  known,  since  this  knowledge  will 
have  an  impact  on  the  exercise  of  achieving  it.  The  encompassing  notion  of  this  compo¬ 
site  strategy  is  “Determine  what  is  currently  happening  with  tool  development,  what  that 
implies  in  regards  to  the  requirements  on  frameworks,  and  how  that  impacts 
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convergence.” 

3.3.3  Approaches  to  Logical  Schema 

This  issue  was  a  merger  of  two  other  suggestions: 

•  “Include  schema  definition  in  the  process  of  convergence.” 

•  “Find  common  schema  for  these  two  systems  (PCTE  and  ATIS),  since  it  is  still 
possible  to  do  so.” 

[See  Appendix  D  for  a  full  listing  of  all  of  the  issues  that  were  enumerated  at  the  Confer¬ 
ence,  together  with  the  itemized  vote  counts  for  each.] 
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4.  CONSOLroATED  GOALS,  STRATEGIES,  AND  ACTIONS  FOR 
ACHIEVING  CONVERGENCE 

Following  the  “brainstorming”  exercise,  the  participants  consolidated  the  previ¬ 
ous  discussions.  Consolidation  was  done  first  by  examining  the  sometimes  conflicting 
goals  of  convergence  that  had  been  implied  in  the  discussion.  They  then  agreed  on  a  list  of 
actions,  a  list  of  consensus  items  (e.g.,  ones  that  all  participants  had  agreed  to),  and  a  list 
of  unresolved  issues. 

4.1  Goals  of  the  Convergence  Exercise 

Most  of  the  positions  that  had  been  stated  during  the  Conference  were  based  on 
an  implicit  sense  of  the  goal  of  frameworks  convergence;  e.g.,  “why  are  we  doing  this 
exercise?”  Since  some  of  the  positions  were  in  conflict,  the  goals  that  supported  those 
positions  were  examined  and  contrasted.  One  benefit  of  this  was  to  put  the  long  list  of 
suggested  issues  into  some  perspective.  It  also  served  to  expose  other  issues  related  to 
short-term  and  long-term  strategies.^ 

Possible  goals  of  frameworks  convergence  include: 

Goal  To  achieve  a  new,  monolithic,  aggregate  standard. 

Goal  To  retain  both  Object-Oriented  and  Entity-Relationship  “sides”,  but  to  achieve 
interoperability  of  the  sort  where  the  capabilities  running  on  the  Object- 
Oriented  side  and  the  capabilities  running  on  the  ERA  side  dynamically  share 
data. 

Goal  To  achieve  data  sharing  only  before  and  after  the  execution  of  units  of  activity  ( 
a  restricted  form  of  ii). 

Goal  Continued  existence  of  multiple  frameworks,  adding  support  to  make  porting 
tools  from  one  framework  to  another  easier  and  less  costly  (minimal  conver¬ 
gence). 


1.  The  bases  for  this  section  were  presentations  by  Bob  Balzer  of  USC/ISI  and  Ian  Thomas  of  Hewlett- 
Packard. 


Goal  To  have  independent  but  compatible  standards.  Inherent  in  this  is  both  the 
notion  of  “profiles”,  as  sets  of  harmonized  standards,  and  the  assumption  that 
existing  standards  can  be  subdivided  into  compatible  pieces. 

Goal  To  reduce  distance  between  existing  standards  by  extending  them  toward  each 
other. 

Goal  To  have  several  complementary  standards  (similar  to  the  fifth  goal  ). 

4.1.1  Comparison  of  Goals 

In  comparing  the  relative  merits  of  these  goals,  discussion  touched  on  some 
inherent  difficulties  in  each.  In  particular,  for  any  of  the  alternative  goals  that  implied 
layering  PCTE  and  ATIS,  services  such  as  object  management  or  process  management 
necessitate  that  some  choices  must  be  made  at  one  level  that  will  constrain  other  choices 
at  another  level.  It  may  be  difficult  to  harmonize  such  choices  between  PCTE  and  ATIS. 
One  hypothesis,  that  the  various  issues  of  convergence  could  be  approached  incremen¬ 
tally,  with  specific  tactics  for  distinct  sets  of  issues,  was  countered  with  the  contrary 
hypothesis  that  the  substructures  of  such  interfaces  are  necessarily  highly  cohesive,  and 
are  not  easily  separable  nor  recombinable. 

It  was  noted  that  the  second  goal,  retaining  both  0-0  and  ER  “sides,”  may 
require  more  substantial  convergence  in  order  to  satisfy  the  requirement  for  interaction, 
compared  to  that  required  to  the  third  goal,  which  merely  requires  “batch”  oriented 
interoperation.  Also,  for  the  fourth  goal,  trying  to  reduce  porting  costs,  the  task  at  the 
present  of  reworking  a  tool  from  ATIS  to  PCTE  involved  reworking  interfaces  (easy), 
data  models  (harder),  and  control  models  (maybe  impossible). 

4.2  Agreements  Reached  At  The  Conference 

The  participants  of  the  Conference  reached  agreement  on  nine  items. 

Agreement  1.  0-0  methods  and  technology  should  be  provided  and  supported;  the  ori¬ 

ginal  consensus  was  for  0-0  support  in  environments,  but  this  was  later 
changed  to  support  in  frameworks.  NB:  This  change  in  focus  did  not 
receive  unanimous  support.  A  key  point  in  this  agreement  was  that 
emphasis  is  on  0-0  technology  because  it  solves  real  software  engineer¬ 
ing  problems  and  is  not  just  a  technology  fad. 

Agreement  2.  Itemize  several  recommended  areas  where  individual  mechanisms  for 
commonality  between  ATIS  and  PCTE  could  be  found.  These  included 
schema,  definitions  of  types  of  methods  (with  possible  concern  of  granu¬ 
larity),  versioning,  transactions,  distribution  of  data  security,  multiple 
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Agreement  3. 


Agreement  4. 


Agreement  5. 


Agreement  6. 


Agreement  7. 


use,  multiple  schema,  and  multiple  inheritance. 

The  third  and  fourth  agreements  were  actually  statements  rather  than 
agreements:  the  third  states  that  because  ATIS  is  in  a  much  earlier  stage 
of  its  evolution,  it  is  therefore  more  malleable,  and  also  more  incom¬ 
plete. 

The  fourth  agreement  states  that  the  PCIS  activity  is  the  probable  ave¬ 
nue  for  evolution  of  PCTE.  Action  items  were  issued  for  both  state¬ 
ments. 

The  fifth  agreement,  also  in  the  form  of  a  statement,  is  an  observation 
that  there  is  no  appropriate  place  in  the  standards  community  fo' 
addressing  framework  issues. 

The  problems  of  commonality  of  schemata,  and  of  commonality  of  types 
and  methods  are  important,  very  hard  to  achieve,  and  very  critical  for 
STARS  to  begin  addressing. 

STARS  should  be  working  to  assure  that  divergence,  whether  perceived 
or  actual,  between  PCTE  and  ATIS  should  not  be  exaggerated  by  a  con¬ 
vergence  exercise. 


The  last  two  points  of  agreement  were,  in  fact,  only  partially  agreed  to  by  all.  However,  it 
was  asserted  that  it  is  possible  in  ATIS  to  separate  the  class  hierarchy  component  from 
the  dispatch  mechanism  component  of  object  oriented  interface  mechanisms  (such  as  in 
ATIS),  and  that  there  was  value  in  first  doing  so,  and  then  addressing  the  relationship 
between  the  dispatch  mechanism  and  the  control  binding  mechanism  in  PCTE.  At  least 
the  vendors  that  were  attending  the  Conference  who  are  making  investments  in  this  area 
are  exploring  that  strategy. 


4.3  Action  Items  From  The  Conference 


The  participants  of  the  Conference  suggested  seven  action  items  to  STARS. 

Action  Item  1.  STARS  should  find  a  vehicle  for  participating  in  the  exercise  of  finding  a 
method  dispatch  mechanism  that  is  compatible  with  PCTE.  STARS  should 
encourage  the  convergence  of  these,  thereby  possibly  minimizing  the  distance 
between  that  result  and  ATIS 

Action  Item  2.  STARS  must  identify  a  process  for  resolving  unresolved  issues  raised  in 
this  meeting  (cf.  Section  5  below). 

Action  Item  3.  With  regard  to  the  second  item,  STARS  should  establish  a  process  to 
analyze  similarities  and  differences  between  PCTE  and  ATIS,  and  identify 
possible  reconciliations.  Very  early  steps  of  such  analysis  have  been  suggested 
in  this  meeting.  The  identification  of  possible  reconciliations  is  an  urgent  item  if 
it  is  to  have  a  positive  effect.  Clear  commitment  by  STARS  on  the  convergence 
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issue  must  exist  by  June;  this  requires  at  least  the  analysis  to  be  completed. 

Action  Item  4.  STARS  (and  other  interested  parties)  should  stimulate  the  establishment 
of  a  home  in  the  standards  world  for  framework  standardization  issues. 

Action  Item  5.  To  address  Agreement  7,  SIARS  should  exert  leverage  in  both  the  PCTE 
evolution  (e.g.,  PCIS)  and  ATIS  evolution  communities  (e.g.,  the  CASE 
Integration  Services  Consortium). 

Action  Item  6.  STARS  should  implement  the  following: 

a.  Include  user  scenario  work  revealed  here  (i.e.,  the  Unisys  work  leading  to  the 
central  interface  approach  above)  in  the  STARS  Process  activities. 

b.  Use  the  process  work  carried  on  within  STARS  to  guide  and  influence  STARS’ 
framework  decisions 

c.  Determine  which  client  community  is  most  impacted  by  convergence  concerns, 
and  then  determine  how  to  exploit  this  knowledge  in  defining  the  steps  of  the 
convergence  process.  (T'’is  action  is  based  on  “brainstorming”  items  8,  10,  14, 
21,  and  37 

Action  Item  7.  STARS  should  define  a  relationship  with  the  PCIS  activity,  and  should 
determine  the  means  for  using  that  relationship  to  achieve  Actions  1-6 

4.4  Unresolved  Issues 

The  participants  of  the  Conference  discussed  the  following  items,  but  failed  to 

reach  significant  agreements  concerning  them.  These  items  are: 

a.  How  much  convergence  is  actually  necessary  if  STARS  is  to  achieve  the  anti¬ 
cipated  benefits  to  tool  construction  and  interoperation. 

b.  Whether  or  not  STARS  should  base  framework  evolution  on  ECMA/PCTE, 
i.e.,  whether  or  not  to  view  the  introduction  of  0-0  capabilities  as  “value- 
added”  to  the  existing  PCTE  proposed  standard. 

c.  Whether  or  not  STARS  should  base  framework  evolution  on  UNIX,  i.e., 
whether  or  not  to  view  the  introduction  of  0-0  capabilities  as  “value- 
added”to  UNIX  (or,  better,  POSIX). 

d.  Whether  STARS  should  investigate  successful  interoperability  exercises  that 
have  been  done  in  the  heterogenous  database  community. 

e.  Whether  STARS  should  embrace  monolithic  versus  partitionable  standards. 


ACRONYMS 


APSE 

AXIS 

CAIS 

CASE 

CIS 

CPL 

COTS 

DARPA 

DoD 

ECMA 

EIS 

ER 

ERA 

IDA 

IRDS 

ISEE 

ISTO 

KAPSE 

KIT 

KITIA 

MCCR 

MLS 

NFS 

NGCR 

NIST 

0-0 

OODB 

OOISS 


Ada  Programming  Support  Environment 
A  Tool  Integration  Standard 

Common  Ada  Programming  Support  Environment  Interface  Set 

Computer-Assisted  Software  Engineering 

CASE  Integration  Services 

Common  Prototyping  Language 

Commercial  off  the  Shelf 

Defense  Advanced  Research  Project  Agency 

Department  of  Defense 

European  Computer  Manufacturers’  Association 
Engineering  Information  System 
Entity-Relationship 
Entity-Relationship-Attribute 
Institute  for  Defense  Analyses 
Information  Resource  Dictionary  System 
Integrated  Software  Engineering  Environment 
Information  Science  and  Technical  Office 
Kernel  Ada  Programming  Support  Environment 
KAPSE  Interface  Team 

KAPSE  Interface  Team  with  Industry  &  Academia 

Mission-Critical  Computer  Resources 

Multilevel  Security 

National  File  System 

Next  Generation  Computing  Resources 

National  Institute  for  Standards  and  Technology 

Object-Oriented 

Object-Oriented  Database 

Object-Oriented  Interface  Support  Services 
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OSF 

PC 

PCIS 

PCTE 

POSIX 

SHE 

SQL 

STARS 

SWG 


Open  Software  Foundation 
Personal  Computer 

Portable  Common  Interface  Set  ^ 

Portable  Common  Tool  Environment 

Portable  Operating  System  Interface  for  a  Computer  Environment 
Software  Engineering  Environment 
Structured  Query  Language 

Software  Technology  for  Adaptable,  Reliable  Systems  # 

Software  Working  Group 
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APPENDIX  A 


CHARTER  OF  THE  FRAMEWORKS  CONVERGENCE  MEETING 


Meeting  on  Convergence  of 
Frameworks  for 

Software  Engineering  Environments 

January  22-23,  1991 

On  January  22-23,  1991,  a  meeting  on  the  possible  convergence  of  commercial 
frameworks  for  Software  Engineering  Environments  will  be  hosted  by  the  National  Insti¬ 
tute  for  Standards  and  Technology  in  Gaithersburg,  Maryland,  under  the  sponsorship  of 
the  Defense  Advanced  Research  Projects  Agency,  Software  Technology  for  Adaptable, 
Reliable  Systems  (STARS)  Program.  The  meeting  is  being  held  with  the  expectation  that 
it  will  produce  a  sharper  understanding  of  the  Software  Engineering  Environment  (SEE) 
framework  options  that  are  available  to  STARS. 

The  purpose  of  the  meeting  will  be  to  establi'^  "’hether  it  is  technically  feasible, 
within  the  STARS  timeframe  of  1991-1993,  to  ct  .verge  existing,  apparently  competing, 
approaches  to  SEE  frameworks  as  re  lecied  in  proposed  interface  standards.  Such  con¬ 
vergence,  if  it  is  technically  feasible,  could  improve  the  prospects  for  marketplace  accep¬ 
tance  of  these  approaches,  and  thereby  speed  tl-e  prcvcss  of  developing  SEEs,  especially 
including  STARS  SEEs.  Of  particular  technical  concern  is  the  apparent  competition 
between  framework  approaches  based  on  ER  models  (for  example,  ECMA/PCTE  and 
CAIS-A)  and  those  based  on  Object  Oriented  models  (for  example,  ATIS),  and  the 
potential  for  converging  these  approaches. 

The  meeting  will  be  by  invitation  only,  and  members  of  governr.:ent,  academia  and  indus¬ 
try  (both  commercial  and  DoD  contractor  industry)  representing  major  efforts  to 
accelerate  the  emergence  and  acceptance  of  viable  SEEs  Programs  with  particular  con¬ 
cern  in  this  area  include; 

•  The  Next  Generation  Computer  Resources  (NGCR)  Program 

•  The  STARS  Program 

•  ECMA/PCTE  Programs 

•  CAIS-A  (MIL-STD  1838A)  related  programs 

•  The  Portable  Common  Interface  Set  (PCIS)  Programme 

•  The  National  Institute  of  Standards  and  Technology  ISEE  activity. 
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A  few  other  individuals  will  also  be  invited. 


While  each  of  the  programs  listed  has  particular  interest  in  the  goals  of  this  meet¬ 
ing,  the  STARS  program  depends  most  urgently  on  its  results  and  will  be  the  principal 
consumer  of  its  products.  Following  is  a  more  detailed  description  of  the  background 
leading  to  the  meeting,  the  objectives  of  the  meeting,  and  the  results  that  are  anticipated. 


O') 


» 


» 


i 
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1.  BACKGROUND 

1.1  SEE  Framework  Efforts 

Several  efforts  currently  specifying,  designing,  and/or  implementing  Software 
Engineering  Environments  (SEEs)  or  SEE  frameworks  are  also  proposing  standards  for 
tool  interfaces  and  object  management  services.  These  efforts  often  have  overlapping 
goals,  and  as  a  consequence  have  proposed  standards  that  appear  to  be  in  conflict. 
Numerous  attempts  to  evaluate  the  current  developments  and  future  trends  in  such  inter¬ 
faces  have  been  conducted  in  recent  years  and  are  continuing.  Interactions  among 
developers  and  evaluators  have  surfaced  an  emerging  hypothesis  that  some  approaches, 
previously  considered  essentially  in  conflict,  may  in  fact  be  complementary.  Conse¬ 
quently,  it  may  be  possible  to  develop  standards  that  are  ’’convergent”  rather  than  com¬ 
petitive,  in  that  they  operate  in  conjunction  with  each  other,  or  may  be  merged  into  single 
standards  encompassing  and  replacing  the  complementary  standards. 

1.2  Potential  Impact  Of  Convergence  On  Tool  And  Framework  Developers 

Currently,  numerous  framework  standards  are  competing  for  acceptance,  none  of 
which  addresses  satisfactorily  all  the  problems  facing  environment  and  tool  developers. 
This  situation  makes  it  extremely  difficult  for  tool  developers  to  determine  which  plat¬ 
forms  are  worthy  of  (re)hosting  their  tools.  Consequently,  it  is  difficult  for  framework 
developers  to  demonstrate  the  efficacy  of  their  approach  with  respect  to  existing  tools. 
The  causes  of  this  situation  are  self-perpetuating  —  it  takes  so  long  to  demonstrate  ade¬ 
quacy  of  new  frameworks  that  alternate  approaches  arise  and  undercut  the  motivation  to 
commit  to  the  original  frameworks. 

Successful  convergence  would  result  in  the  simultaneous  satisfaction  of  a  broader 
range  of  tool  and  environment  developer  needs  than  can  be  satisfied  by  the  contributory 
standards  individually,  and  thereby  would  broaden  the  applicability  of  the  contributory 
standards.  This  in  turn,  could  clarify  the  marketplace  opportunities  for  tool  developers, 
and  provide  growth  paths  for  framework  and  environment  developers.  For  these  results 
to  occur,  it  will  be  necessary  to  establish  satisfactory  understanding  of  the  relationship 
between  the  convergent  standards  and  the  architectures  of  conforming  environments. 
Determining  that  there  exist  viable  architectures  that  gain  the  benefits  promised  by  con¬ 
vergence  is  one  of  the  major  technical  tasks  in  a  convergence  effort. 

1.3  STARS 

The  STARS  Program  is  presently  choosing  a  set  of  noncompeting  standards  for 
use  as  the  basis  of  an  open  architecture  framework.  This  framework  will  be  the  basis 
for  several  domain-specific  Software  Engineering  Environments  (SEEs)  that  will  be 


23 


I 


used  by  various  DoD  agencies  to  implement  mission-critical  software  projects.  To  the 
greatest  extent  possible,  these  SEEs  will  be  populated  by  commercial,  off-the-shelf 
(COTS)  software.  The  STARS  SEEs  are  planned  to  be  in  use  starting  in  1993  and  thus  it 
is  vital  that  the  standards  selected  by  STARS  have  the  greatest  chance  of  gaining  wide 
currency,  particularly  in  the  commercial  marketplace. 

1.4  Potential  Impact  Of  Framework  Convergence  On  STARS 

If  standards  that  are  candidates  for  selection  by  STARS  are  in  essential  conflict, 
STARS  may  be  forced  to  make  an  early  choice  among  the  competitors.  Subsequently,  the 
degree  of  success  that  the  selected  standards  achieve  in  the  competitive  commercial 
environment  marketplace  (largely  reflected  by  the  number  and  variety  of  the  tools 
developed  to  work  on  these  standards)  may  then  determine  the  success  of  STARS  SEEs. 

If  certain  key  standards  can  be  made  “convergent”  and  do  not  thereby  lose  sta¬ 
ture  in  the  commercial  marketplace  competition,  then  an  important  risk  in  the  STARS 
SEE  program  would  be  significantly  reduced.  STARS  may  not  need  to  make  such  early 
choices,  since  STARS  SEE  architectures  could  be  based  on  multiple  standards  and  the 
implementation  of  such  architectures  could  be  coordinated  with  the  evolution  of  imple¬ 
mentations  supporting  those  standards.  For  this  benefit  to  actually  be  realized,  any 
required  adaptations  of  the  standards  to  become  convergent  would  have  to  be  achieved  in 
the  near  future  (perhaps  within  a  year),  and  the  commitment  to  achieve  such  convergence 
would  need  to  be  made  in  the  next  few  months. 


2.  PURPOSE  OF  THIS  MEETING 


The  purpose  of  the  meeting  will  be  to  establish  whether  or  not  it  is  technically 
feasible  to  converge  existing,  apparently  competing,  approaches  to  Software  Engineering 
Environment  (SEE)  frameworks  as  reflected  in  proposed  interface  standards.  Of  particu¬ 
lar  technical  concern  is  the  apparent  competition  between  framework  approaches  based 
on  ER  models  (for  example,  ECMA/PCTE  and  CAIS-A)  and  those  based  on  Object 
Oriented  models  (for  example,  ATIS),  and  the  potential  for  converging  these 
approaches.  The  areas  in  which  these  approaches  differ  are  perceived  by  some  observers 
as  the  central  opportunities  for  convergence,  and  will  be,  at  least  initially,  the  focus  of  the 
meeting.  These  areas  include: 

•  Data  model:  eg,  ERA  vs.  0-0; 

•  Granularity:  eg,  “files”  vs.  bits,  interactions  per  day,  minute,  second,  mil¬ 
lisecond; 

•  Access  control:  eg,  MLS,  Discretionary  access  control,  unconstrained  access; 

•  Process  control:  eg.  Interprocess  Control  and  Communication,  etc.; 

•  Change  control:  eg,  object  locking,  transaction  management  (long-term,  short¬ 
term,  nested,  etc.); 

•  Others  to  be  identified. 

There  are  several  specific  objectives  for  this  meeting: 

1.  Identify  the  ways  (if  any)  in  which  the  hypothesized  potential  for  convergence  is 
well-founded  among  the  set  of  efforts  represented  by  the  attendees.  This  objective  is 
to  be  achieved  on  technical  grounds:  if  there  is  no  technical  basis  for  convergence, 
an  economic/political  basis  would  probably  not  arise,  and  would  certainly  be  insuf¬ 
ficient  if  it  did. 

2.  Identify  whether  or  not  special  actions  will  be  required  in  order  to  achieve  conver¬ 
gence.  Such  special  actions  might  include  specific  accommodations  on  the  part  of 
some  efforts,  or  oiher  community  actions  that  may  go  beyond  the  represented 
efforts.  If  such  actions  are  required,  identify  alternate  approaches  to  achieving 
them. 

3.  Identify  the  degree  to  which  there  is  interest  among  key  parties  to  achieve  conver¬ 
gence. 
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Of  these  objectives,  the  first  is  primary.  Initial  approximations  to  the  others  are 


sufficient  for  this  meeting. 
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3.  RESULTS 


The  meeting  will  have  both  tangible  and  intangible  results; 

3.1  Report 

The  minutes  and  decisions  of  the  meetings  will  be  distributed  for  comment  by  the 
invited  members  on  or  before  February  15,  1991.  Thereafter  the  minutes  and  decisions 
of  the  meetings  will  be  published  and  disseminated  by  IDA  for  use  by  STARS  and  other 
concerned  Government  agencies. 

3.2  Consensus/Roles 

The  meeting  will  help  to  establish  the  degree  to  which  there  is  technical  consensus 
on  the  convergence  hypothesis.  In  addition,  it  may  clarify  the  possible  involvement  in 
the  STARS  program  of  one,  some,  or  all  of  the  efforts  represented. 


APPENDIX  B 


CAPSULE  BIOGRAPHIES  OF  PARTICIPANTS 


Robert  Balzer,  USC/ISI; 

is  currently  working  on  the  DARPA  CPL  project;  has  worked  extensively  with 
frameworks  issues. 

Frank  Belz,  TRW  (Chair): 

is  TRW  Technical  Fellow;  has  been  involved  in  environment  activities  since  late 
70’ s;  is  currently  a  co-PI  on  DARPA’ s  Arcadia  and  Common  Prototyping  System 
programs;  will  serve  as  a  PCIS  “Expert”. 

Hugh  Beyer,  DEC: 

has  been  involved  in  standards  work  for  the  last  5  years;  is  currently  involved  in 
ATIS  work  and  repository’  development  projects. 

Eric  Black,  Atherton  Technology: 

is  Principle  Architect  of  the  Software  Backplane  commercial  product  of  Atherton; 
noted  that  PCTE  and  ATIS  convergence  is  desirable  (to  Atherton)  for  obvious 
commercial  reasons. 

David  Carney,  IDA: 

is  currently  chair  of  the  STARS  working  group  preparing  the  Requirements  and 
Criteria  and  Open  Architecture  Framework  for  the  STARS  SEE. 

Currie  Colket,  AJPO: 

is  currently  Deput"  of  the  Ada  Joint  Program  Office  working  for  the  NATO 
SWG/APSE  program  and  also  for  the  PCIS  effort;  pointed  out  that  the  PCIS  stan¬ 
dard  will  be  more  than  convergence  of  CAIS-A  and  PCTE+,  and  that  the  PCIS 
effort  is  interested  in  a  commercial  standard  that  platform  vendors  will  support. 

Ed  Cuoco,  DEC: 

is  the  Business  Manager  for  DEC’S  Cohesion  program;  added  a  statement  con¬ 
cerning  dec’s  goal  of  providing  products  which  satisfy  its  customers. 


Bob  Ekman,  IBM: 

is  deputy  architect  for  the  IBM  STARS  project;  is  currently  on  the  working  group 
that  is  establishing  an  Open  Architecture  Framework  and  Requirements  and  Cri¬ 
teria  for  STARS  SEE. 

Herman  Fischer,  Mark  V  Systems: 

is  Chairman  of  Mark  V  Systems,  Limited;  has  worked  with  issues  related  to 
frameworks  and  environments  since  the  CAIS/KIT/KITIA. 

David  Goiffon,  Unisys: 

is  manager  of  the  Unisys  Repository  Group,  and  is  also  the  Architect  of  Unisys 
Repository’;  noted  that  there  is  a  interest  in  using  frameworks  throughout  Unisys. 

William  Hodges,  Boeing: 

is  Program  Manager  for  the  Boeing  STARS  program;  pointed  out  the  need  to  be 
cognizant  of  the  requirements  of  the  end  user. 

Mansour  Kavianpour,  IBM: 

is  currently  working  on  the  AIX  CASE  environment,  and  is  architect  of  the  AIX 
Repository  Manager. 

John  Kramer,  DARPA/STARS: 

is  director  of  the  STARS  Program,  and  has  been  involved  in  frameworks  and 
environments  activities  from  the  inception  of  the  CAIS/KIT/KITIA. 

Regis  Minot,  GIE  Emeraude: 

is  a  designer  of  PCTE,  and  has  been  involved  with  the  program  since  its  inception; 
also  offered  to  supply  any  needed  information  on  the  status  of  the  Emeraude 
implementation  of  PCTE. 

Bob  Munck,  Unisys: 

is  Deputy  Architect  for  the  Unisys  STARS  program;  represents  a  large  body  of 
experience  in  CAIS-A,  and  on  on  frameworks  issues  in  general. 

Patricia  Oberndorf,  NADC: 

has  worked  on  environments  for  fifteen  years,  in  particular  leading  CAIS  through 
its  development;  is  now  establishing  Navy  interface  standards,  including  those  for 
the  Next  Generation  Computer  Resources/ Project  Support  Environments. 
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Gary  Pritchett,  SofTech: 

is  currently  manager  of  the  SofTech  CAIS-A  project  sponsored  by  the  Ada  Joint 
I  Program  Office;  program  has  defined  CAIS-A,  as  well  as  producing  both  VAX  & 

UNIX  implementations  of  CAIS-A. 

Andres  Rudmik,  Software  Productivity  Solutions: 

^  is  chairman  of  the  CASE  Integration  Services  (CIS)  Consortium;  is  also  currently 

doing  Air  Force  work  on  concurrent  engineering. 

Ian  Thomas,  Hewlett-Packard: 

is  Software  Engineer  in  the  Engineering  Systems  Division,  and  worked  with  Bull 
•  from  1986-1989  on  PCTE;  is  currently  working  on  the  HP  Softbench  project,  and 

expressly  considering  evolutions  of  Softbench  in  the  context  of  PCTE. 

William  Wong,  NIST: 

^  is  working  on  the  NIST  Software  Environment  Program,  developing  documenta¬ 

tion  on  the  area  of  software  environments  to  be  issued  as  a  FIP;  noted  that  the 
PCTE  and  ECMA  Reference  Model  activities  will  be  important  for  refining  the 
eventual  NIST  documents. 
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APPENDIX  C 


•  TRANSCRIPT  OF  THE  CHAIRMAN’S  SUMMARY  OF  THE  MEETING 
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Frank  Belz: 

I  have  been  through  an  interesting  process  and  this  part  of  the  process  is  basically  for  us 
as  a  group  to  review  with  those  of  you  from  STARS  and  ISTO  who  are  here  now  what’s 
just  happened.  So  I  want  to  cover  a  little  bit  of  the  process  to  let  you  know  the  structure 
that  we  went  through.  And  most  of  you  (not  Teri  Payton)  have  been  sitting  through  the 
last  phase  of  what  we  did.  So  I  want  to  catch  you  up  on  what  happened  previous  to  that 
very  quickly. 

During  the  first  part  of  the  meeting,  we  basically  did  information-sharing  to  establish  a 
context.  So  several  people  volunteered  to  get  up  and  talk  about  what  their  work  was,  and 
how  it  related  to  the  issue  of  convergence.  The  result  of  that  was  a  bunch  of  papers  which 
are  part  of  the  repository  '  r  is  available  and,  I  suspect,  will  migrate  to  whoever  needs  to 
have  [them]  in  STARS. 

After  that,  we  heard  from  some  people  who  have  already  been  doing  some  experiments 
in  convergence  of  object-oriented  capabilities  in  the  context  of  PCTE  convergence;  there 
were  different  strategies  described.  There  were  several  discussions  that  evolved  from 
those  presentations.  After  that  we  did  some  other  activities,  and  this  morning  Bob  Balzer 
got  up  and  gave  a  summary  report  of  what  those  discussions  were  about.  [Reference  to 
sUde  #BB.l] 

Basically  those  exercises  dealt  with  what  is  involved  if  you  want  to  provide  interfaces  that 
are  accesses  to  a  common  repository;  e.g.,  if  the  interfaces  have  different  styles,  and  one 
style  is  object-oriented  style  and  one  is  an  ERA  style.  The  first  experiment  was  the  one 
conducted  by  the  DEC  group  in  Italy.  It  amounted  to  building  an  object-oriented  data 
base  and  constructing  an  ATIS  set  of  interfaces  and  a  PCTE  set  of  interfaces  (actually 
subsets  of  these).  The  PCTE  interface  implementation  was  in  terms  of  method  dispatches 
that  were  driven  by  the  object-oriented  data  base.  In  order  to  do  that,  this  underlying 
model  required  semantics  that  were  not  available  in  ATIS.  So  they  put  semantics  from 
PCTE  in  the  lower-level  structure.  Their  strategy  was  to  build  something  down  at  the  bot¬ 
tom  that  has  sufficient  capability  to  serve  the  purposes  of  superior  models,  and,  if  neces¬ 
sary,  add  to  this  capability  down  here  things  that  weren’t  present  in  either  one. 
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Bob  pointed  out  that  another  way  to  do  it  (which  is  not  whai  they  did)  is  to  construct 
something  down  here  [pointing  to  both  “semantics”  boxes]  which  was  arbitrary  (doesn’t 
matter  what  it  is)  and  there’s  a  mapping  between  PCTE  interfaces  and  AXIS  interfaces  as 
necessary.  That’s  entirely  a  dual  [interface  solution]. 

Bill  Hodges:  Frank,  can  I  help  you  a  little  bit  there?  This  particular  architecture  for  their 
experiment  was  the  last  of  several  attempts.  They  did  choose  to  first  try  to  put  ATIS  on 
top  of  PCTE  and  found  some  reasons  why  that  was  not  acceptable  and  chose  to  go  this 
route. 

Frank  Belz:  So  what  they  did  fiurst  is  something  like  this  [pointing]  which  is  the  other  way 
around;  you  start  with  something,  for  example,  PCTE  which  is  an  ERA  data  model  with 
its  own  capabilities,  and  you  map  ATIS  functionality  and  PCTE  functionality  at  this  level. 
So  that’s  what  they  tried  and  they  didn’t  get  to  work. 


DUAL  INTERFACES 


» 


(BB.l:  Foil  drawn  by  R.  Balzer) 


At  various  times,  several  people  in  the  community  and  in  this  group  proposed  a  variation 
of  this,  with  a  strategy  here  which  looked  like  this  [reference  to  Slide  RM.l]  and  I’m  sure 
that  everybody  in  this  room  has  seen  diagrams  that  look  like  this  one  time  or  another. 
There  was  a  fair  amount  of  discussion  about  this  in  which  this  is  a  variant  of  something 
which  was  discussed  as  the  ‘wedding  cake’  model,  in  which  tools  have  access  to  various 
levels  of  the  interfaces  as  necessary  to  be  able  to  integrate  them  in  the  system  at  some 
level  of  integration.  So  truly  foreign  tools  could  reside  on  a  visible  POSIX  interface, 
PCTE-only  tools  can  reside  on  a  PCTE  interface,  ATIS  tools  can  reside  on  a  set  of  com¬ 
mon  services  (which  is  essentially  the  thing  that  the  Italian  team  was  unsuccessful  at  try¬ 
ing  to  achieve),  and  some  tools  might,  in  fact,  require  both  object-oriented  services  and 
PCTE  services;  there  was  a  lot  of  discussion  about  all  of  this. 

The  end  result  (and  my  conclusion  is)  that  any  of  these  strategies  are  strategies  for  evolv¬ 
ing  the  mechanisms  which  allow  you  to  use  capabilities  that  depend  on  an  object-oriented 
model  or  a  PCTE  model  in  the  same  environment  over  time.  They  don’t  necessarily 
imply  that  you  are  going  to  do  any  convergence  exercise.  But  they  do  supply  you  with  an 
evolutionary  mechanism  to  implement  functionality  as  part  of  the  process.  Now  with 
regard  to  the  difficulty  associated  with  this,  one  of  the  points  that  was  made  can  be  easily 
illustrated  with  this  diagram  [slide  RM.l]. 

It’s  all  very  nice  to  have  tools  stacked  in  this  fashion,  but  if  you  want  tools  to  interoperate, 
you  haven’t  gone  very  far  in  achieving  that  in  this  stage  of  the  game.  Because  in  order  to 
achieve  that,  you  have  to  have  some  agreement,  not  only  about  what  the  bits  are  (that  are 
going  back  and  forth),  what  the  control  protocols  are,  but  what  those  bits  mean.  And  in 
order  for  that  to  occur,  you  have  to  have  some  common  model  which  may  be  expressed  in 
a  class  hierarchy  in  an  object-oriented  system,  or  may  be  expressed  in  a  network  of  an 
ERA  database.  But  you  have  to  have  some  model  of  what  it  means  to  have  that  data  and 
what  the  relationships  are  if  any  particular  data  in  fact  relate  to  any  other  data,  you  don’t 
get  that  from  this.  That’s  another  activity.  That’s  another  thing  that  has  to  happen.  That 
which  has  to  happen  is  (1)  more  difficult  than  any  of  this,  and  (2)  is  absolutely  essential  to 
occur,  and  activity  should  be  conducted  to  see  how  that  will  proceed. 

So  Bob’s  way  of  classifying  the  issues  is  this:  What  I’ve  just  talked  about  is  shared 
schema,  i.e.,  at  a  logical  level,  you  need  to  have  an  idea  of  what’s  happening  in  part  of 
the  environment  of  the  tools  that  are  depending  upon  the  PCTE  structure,  ATIS  struc¬ 
ture,  etc.  You  have  to  have  shared  logical  schema  which  may  be  realized  in  different 
ways  to  serve  as  a  basis  for  establishing  interoperability. 


0-0  Common  Service 


PCTE 


POSIX,... 


Then  there’s  the  second  issue  which  I’ll  call  shared  infrastructure.  What  is  true  about  this 
system  is  that  there  are  a  lot  of  issues  addressed  in  the  PCTE  system  that  are  parameter¬ 
ized  out  of  the  current  specification  of  ATIS.  For  example:  the  notion  of  process  and  tran¬ 
sactions;  the  notion  of  security  and  access  control  mechanisms;  the  notions  of  view  adop¬ 
tions  are  different;  concurrency  control;  differences  between  the  models  of  versioning. 
So  there  are  things  which  are  either  simply  deferred  in  the  AXIS  community,  or  for  which 
a  different  solution  has  been  constructed  to  address  these  issues  than  is  present  in  the 
PCTE  community.  So  now  the  question  is,  how  do  you  deal  with  this?  Bob’s  hypothesis 
was  that  in  the  context  of  this  evolutionary  development  capabilities,  there  were  inter¬ 
mediate  tactics  that  could  be  used  to  address  some  of  these  issues.  I’m  not  going  to  go 
through  all  these  tactics... 


[some  portions  missing  during  tape  change...] 


[Note  from  Belz:  the  basic  idea  expressed  in  the  missing  transcript  was:  Bob’s  hypothesis 
that  the  shared  infrastructure  issues  above  could  be  addressed  incrementally  with  tactical 
approaches  was  challenged  by  Ian’s  ...] 

...position  that  these  things  aren’t  isolatable;  they  represent,  in  fact,  a  set  of  issues  that 
have  to  be  resolved  by  a  significant  engineering  exercise,  and  that  it’s  the  interaction 
among  all  of  these  with  the  primary  functionality  that  it  has  provided  that  determines  the 
adequacy  of  the  engineering  exercises  provided.  And  so  the  hypothesis  was  that  this  stra¬ 
tegy  may  work  in  a  limited  way,  but  there  is  a  discontiruity:  you  can’t  get  from  here  to 
something  that’s  new  and  coherent  and  also  convergent,  without  having  a  real  shift  in 
structure. 

Jack  Kramer:  As  a  good  example  of  that:  you  can’t  just  take  basically  an  arbitrary  secu¬ 
rity  model  and  arbitrary  standard  and  expect  them  to  work  well  together. 

Frank  Belz:  Now  that  disagreement  is  completely  unresolved  at  this  point.  The  disagree¬ 
ment  was  stated;  and  you’re  going  to  see  strategies  for  addressing  it  in  the  suggested 
actions,  in  the  issues  agreed  upon,  and  in  the  issues  not  agreed  upon. 


Now  on  this  slide  [Slide  AR.l],  the  upper  part  is  representative  of  everything  I  have  just 
discussed.  The  bottom  is  addressing  in  a  more  abstract  way,  what  I  just  talked  about  with 
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regard  to  how  do  you  address  issues  like  versioning,  transactions,  and  things  of  that  sort. 
Andy  Rudmik  has  suggested  that  some  of  these  were  amenable  to  being  addressed 
independent  of  the  underlying  mechanisms.  So,  for  example,  it  may  be  that  if  you  look  at 
the  versioning  model  over  some  exercise,  you  can  come  up  with  a  way  in  which  it  makes 
sense  abstractly  to  merge  the  notions  of  the  versioning  model  that  would  be  supported  in 
something  like  a  PCTE  or  something  like  an  AXIS.  Having  that  abstract  characterization, 
you  can  define  minimal  maps  for  realization  in  these  two  systems.  In  those  maps,  you  may 
achieve  in  terms  of  whatever  versioning  model  that  you  support  directly  PCTE  and  it  may 
be  created  by  revising  or  extending  or  specializing  classes  that  already  exist  in  the  ATIS 
class  hierarchy.  But  the  strategy  basically  was,  work  together  with  members  of  these  com¬ 
munities;  see  if  you  can  establish  a  target;  and  map  that  target  back  down  into  the 
mechanisms.  By  doing  that,  you  wind  up  minimizing  the  distance.  You  also  create  pres¬ 
sure  for  these  standards  to  fall  into  direct  support  for  the  kinds  of  things  that  we  can  agree 
to. 

Now  the  second  thing  that  is  on  this  slide  has  to  do  with  achieving  low-level  infrastructure 
support  that  makes  it  more  possible  to  get  that  scenario  to  work,  i.e.,  PCTE  as  a  base 
technology.  That  has  to  do  with  the  division  in  the  ATIS  world  (or  any  object-oriented  sys¬ 
tem)  between  (1)  the  basic  mechanisms  that  are  part  of  the  kernel  system  —  which  princi¬ 
pally  involves 
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method  dispatching — and  (2)  the  class  hierarchy — which  involves  a  lot  of  the  decisions 
which  the  rest  of  the  capabilities  that  you  put  on  the  tools  are  going  to  depend  on,  i.e.,  the 
common  class  hierarchy  structures.  Ian  Thomas  suggested  that  it  was  essential  that  you 
come  up  with  the  coherent  working  environment,  to  make  sure  that  the  method  dispatch¬ 
ing  mechanisms  provided  in  the  object-oriented  class  were  compatible  with  the  binding  of 
processes  to  data  that  were  defined  here  [pointing  to  the  “PCTE”  box].  That  is,  the  way 
in  which  you  associate,  instantiate,  and  execute  processes  or  things  of  executable  code 
over  here  [pointing  to  the  “  ATIS/O-O”  box]  has  to  be  associated  in  some  sensible  way  to 
the  way  in  which  you  cause  executable  code  to  be  executable  over  here  [pointing  to  the 
“PCTE”  box]. 

It  turned  out  that  four  vendors  at  least  were  addressing  exactly  that  issue  from  different 
points  of  view.  The  general  agreement  was  that  this  was  a  fundamental  question,  and 
everybody  who  was  really  working  hard  on  the  problem  was  addressing  it.  The  general 
problem  was  addressing  that  specific  problem.  Not  necessarily  in  a  common  way;  there 
are  different  ground  rules  for  those  who  want  PCTE  to  be  a  universal  platform  (asking 
how  do  you  change  the  method  of  dispatch  structure  in  ATIS  so  that’s  it’s  compatible  with 
PCTE)  from  those  who  are  interested  in  the  ATIS  world  addressing  the  issue  of  what  has 
to  change  in  PCTE  as  well  as  what  has  to  change  in  ATIS  to  get  these  things  compatible. 
So  it’s  a  difference  of  commitment  to,  or  not  commitment  to,  preserving  PCTE  as  it  now 
stands. 

Periodically  during  this  whole  discussion,  there  were  questions  of  the  form:  “Have  we 
narrowed  our  focus  too  much?”  E.g.,  are  we  Just  looking  at  PCTE  and  ATIS  when,  in 
fact,  there  are  other  issues  to  be  addressed?  One  of  those  might  be  CAIS;  one  of  those 
might  be  the  UNIX  file  system  and  special  things  built  on  it.  Generally  my  assessment  of 
the  reaction  to  that  was:  “Maybe,  but  let’s  keep  going.”  Basically  how  this  group  will 
react  to  that  question  is  “Yes,  we  may  be  overconstraining  the  problem  by  the  approach 
that  we’re  taking,  but  we’re  doing  fine,  so  let’s  keep  going.” 

Oberndorf:  I  think  it’s  fair  to  say  that  anytime  you  have  PCTE  up  there  on  the  slide  (or 
talking  about  it),  we  could  substitute  PCIS  and  the  operations  would  be  similar. 

Belz:  There  were  various  times  where  PCTE,  and  everything  I  just  said,  meant  “what 
we’ve  got  in  hand  today.”  Most  of  the  time,  it  [PCTE]  meant  “This  is  an  abstraction  for 
what  PCTE  evolves  into  as  a  consequence  of  Waltham/Winnersh,  of  PCIS,  of  whatever 
has  happened  or  will  happen. 


Jack  Kramer:  PCIS  is  going  to  assume  a  PCTE  basis...  They’re  going  to  be  driven 
because  of  political  concerns  and  vested  implementation  issues.  There  will  tend  to  be 
much  more  bias  in  the  direction  of  PCTE,  as  opposed  to  being  able  to  start  anew,  and  be 
able  to  take  something  like  ATtS  and  see  how  far  you  can  push  it...  When  we  talk  about 
what  role  STARS  can  play  with  respect  to  PCIS,  you  have  to  be  realistic  about  the  pres¬ 
sures  that  are  going  to  be  brought  to  bear  with  respect  to  PCIS,  because  of  what  the  spon¬ 
sor  says. 

Bob  Munck:  On  the  other  hand,  I  think  that  if  STARS  makes  progress  on  the  object- 
oriented  PCTE  idea,  PCIS  will  be  free  to  go  even  further. 

Belz:  I  don’t  think  we’re  going  to  be  living  with  some  minor  changes,  but  some  compatible 
[missing  words ...]. 

And  substantially  is  not  something  that  can  be  defined  by  the  chairman  of  the  cooperative 
group,  it’s  defined  by  Vice-Presidents  of  companies,  and  that’s  one  of  the  problems  that 
you  have.  Certainly  it  would  seem  to  me  that  the  PCTE  community  as  a  whole  would  want 
to  restrict  changes  to  PCTE  until  it  was  clear  that  substantial  movement  [existed]  for 
adopting  PCTE  as  a  vehicle  for  business  and  that’s  good.  Because  it  leaves  you  with  a 
sound  foundation  but  it  also  exaggerates  the  effect:  As  you  gain  the  basis  for  business  you 
also  gain  a  business  inertia,  a  change  inertia  that  gets  greater.  In  any  case,  I  think  that  for 
purposes  of  deliberations  that  we  have  had,  that  PCIS  was  very  much  a  part  of  the  think¬ 
ing  that  was  being  addressed. 

What  I  have  described  now  took  place  from  about  noon  yesterday  until  about  noon  today. 
What  also  happened  was  an  attempt  to  try  to  focus  on  what  strategies  on  convergence 
could  be  taken  by  STARS  (or  by  anyone)  that  would  help  the  process,  given  that  it’s 
pretty  clear  that  people  perceived  it  as  a  desirable  thing.  So  one  of  the  things  we  did 
toward  the  end  of  the  day  yesterday  was  do  a  brainstorming  session.  The  nominal  task  of 
the  brainstorming  session  was  to  come  up  with  activities  that  would  contribute  to  or  con¬ 
stitute  various  strategies  that  would  be  taken.  What  got  created  is  what  you  see  on  the 
wall. 

What  happened  was  that  we  could  not  restrict  ourselves  to  that  narrow  a  scope  (which 
was  fine...).  What  you  see  up  there  basically  amounted  to  four  major  categories  and  one 
subca»egory  of  brainstorming  items: 

1.  Framework  requirements 

2.  Technical  approaches,  including  whether  you  want  monolithic  standards  or  whether 
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you  want  fragmented  subset  of  standards 

3.  Frameworks  standards  development  and  management  approaches 

4.  Some  suggestions  about  the  importance  of  defining  the  market  place,  i.e.,  “Who  is 
it  that  is  influenced  by  the  convergence  of  these  things,  and  how  does  that  influence 
matter  in  the  process  that  you  take?  ” 

So  we  constructed  that  list,  and  this  morning  we  went  through  a  voting  process  to  deter¬ 
mine  which  was  most  important.  The  process  was  everybody  had  15  votes  and  could 
spend  the  maximum  of  3  on  any  one  issue.  There  were  a  lot  of  voters  that  voted  for  5 
items  with  3  votes  each. 

The  results  of  that  brainstorming  session  were: 

•  "00  on  PCTE:”  a  lot  of  people  wanted  to  explore  the  issue  about  the  relation¬ 
ship  between  object-oriented  mechanisms  and  PCTE  mechanisms,  character¬ 
ized  by  three  of  the  issues  (numbers  7,  13  and  15).  Basically,  they  amount  to 
variations  of  exploring  that  dialogue. 

•  "Useful  Union:”  there  are  several  things  that  I  think  were  most  concisely 
expressed  by  Jack,  which  was  “Find  what  the  minimum  necessary  intersection 
is;  then  factor  back  in  mechanisms  to  achieve  the  capabilities  that  are  present 
already.”  So  this  is  a  strategy  for  achieving  coherence  in  the  design,  while 
achieving  functionality  that’s  required.  And  a  lot  of  people  said  that  should  be 
explored  as  a  part  of  the  process  toward  convergence.  (MB:  Number  fifteen 
specifies  something  where  0-0  and  PCTE  are  coexisting  somewhere  in  the 
environment;  it  says  not  necessarily  on,  but  with.) 

•  "Know  thy  users:”:  If  you  look  at  8,  10,  14,  21,  and  37,  it  should  be  rather 
amusing: 

—  Number  8  says:  “exploit  the  fact  that  tool  writers  (not  users)  are  the 
market  place  for  convergence.” 

—  Number  10  says:  “exploit  the  fact  that  the  tool  users  are  the  market¬ 
place  and  beneficiaries  of  such  convergence.” 

—  Number  14  is  the  encompassing  thing;  it  says:  “figure  out  what’s  going 
on  here;  figure  out  what  the  project  culture  is,  what’s  happening  with 
tool  development  and  figure  out  what  that  implies  with  regard  to  the 
requirements  on  the  framework,  and  how  that  impacts  convergence.” 

—  Number  21  says:  “exploit  the  fact  that  the  ultimate  beneficiaries  of  con¬ 
vergence  are  the  applic  itions  developers.” 
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—  Number  37  asks  if  and  how  0-0  database  vendors  have  a  place  in  this 
whole  process  and  result. 

So  the  end  result  after  having  merged  all  that  into  14  was  that  it  received  a 
pretty  high  vote. 

•  And  then  the  other  one  is  the  issue  we  have  already  described,  which  is  coming 
up  with  some  approach  to  logical  schema. 

There  were  a  number  of  other  issues,  some  of  which  support  those  that  are  on  this  list. 
One  that  I  personally  want  to  point  out  is  number  18;  common  interface  below  PCTE  and 
AXIS. 

[Discussion  about  whether  the  wording  was  accurate,  because  one  version  mentioned 
implementation,  another  mentioned  interface.] 

After  we  took  the  straw  poll,  we  did  not  discuss  it  anymore;  we  came  back  and  dealt  with 
other  issues.  So  this  represents  a  reading  of  this  community,  but  which  was  not  explored 
nor  refined  nor  addressed  specifically.  But  it  does  represent  an  orthogonal  reading  on  all 
the  other  activities  that  we  were  doing. 


This  morning  we  had  two  goals:  one  was  to  address  the  issue  of  what  should  be  done  in 
the  long  term  (how  should  these  issues  be  used;  how  should  you  evaluate  these  things  in 
terms  of  the  long  term  convergence  process),  versus  how  should  we  use  these  to  guide  our 
own  activities  in  the  short  term?  (This  [? convergence? ]  was  defined  to  be  a  long-term 
activity.)  One  conclusion  is  that  many  of  these  things  did  not  have  to  do  with  strategy; 
and  if  you  look  at  the  things  that  did  have  to  do  with  strategies,  they  are  things  that  have 
to  do  with  strategies  but  they’re  not  strategies.  [Puts  up  BB2.] 
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So  what  Bob  tried  to  do  this  morning  was  to  say  “OK,  there  are  some  strategies  that  could 
be  discussed.”  (These  were  discussed,  and  no  choices  were  made  with  regard  to  these, 
either.  So  that’s  another  undecided  that  is  not  on  the  undecided  list.)  Among  the  ones  that 
were  discussed  were,  [pointing  to  BB2]  first,  a  new  aggregate  monolithic  single  standard. 
Second,  interoperability  of  the  sort  where  the  capabilities  running  on  the  object-oriented 
side  and  the  capabilities  running  on  the  PCTE  side  dynamically  share  data.  A  restricted 
version  of  that  [third  item],  where  the  sharing  occurs  only  before  and  after  the  execution 
of  units  of  activity.  So  there  is  a  very  batch-oriented  flavor  to  the  third  option  and  a  very 
interactive  potential  to  the  second  option. 

Then  the  fourth  is  an  even  weaker  situation:  what  you  have  is  various  things  added  to  the 
support  of  the  capabilities  so  that  they  don’t  necessarily  act  together  in  a  single  environ¬ 
ment,  but  for  the  tool  writers,  it’s  easier  to  generate  tools  that  fit  on  both  sides  because 
you’re  reducing  porting  costs  from  various  tactics  you  might  take.  (That’s  a  strategic  goal; 
in  a  sense,  these  are  all  strategic  goals  more  than  how  to  achieve  them.) 

Tricia  added  the  wording  “independent  but  compatible  standards,”  which  provoked  a 
long  and  extensive  discussion  about  what  that  might  mean.  We  discussed  the  issue  of  pro¬ 
files  as  they  are  now  being  used  in  the  standardization  world.  I  won’t  go  into  that.  But  one 
of  them  that  is  talked  about  is  “What’s  the  benefit  of  having  a  reference  model  (like  the 
ISO  reference  model)  as  a  way  of  subdividing  the  issues,  and  providing  a  set  of  standards 
that  address  issues  that  are  characterized  by  subdivisions  that  are  provided  by  the  refer¬ 
ence  models?”  That  question  was  raised  and  no  convergence  was  made. 

Jack  Kramer:  [Something  about  “The  ECMA  Reference  Model  isn’t  sufficient  for  0-0 
systems...”] 

Frank  Belz:So  the  reason  you  see  the  NIST  booklets  out  on  the  table  is  because  there  is  an 
alternate  object-oriented  data  base  reference  model  that  several  people  said  that  this  is 
really  terrific  for  describing  0-0  systems,  and  we’re  not  sure  that  the  ECMA  model  really 
covers  the  things  as  well  in  the  0-0  world  as  this  does. 

So  some  of  you  were  here  during  the  process  when  we  tried  to  say  now  where  are  we  and 
what  have  we  concluded.  So  here’s  our  shot  at  characterizing  that. 

The  original  consensus  on  the  first  agreement  was  that  object  oriented  support  is  coming, 
and  that  is  therefore  a  good  reason  why  it  is  going  to  be  provided  and  it  better  be  sup¬ 
ported.  Actually  what  was  said  was  it  better  be  supported  in  environments,  but  what  I 


wrote  was  that  it  better  be  supported  in  frameworks.  In  the  end  the  group  was  willing  to 
commit  to  this  assertion  (with  the  possible  exception  of  Tricia  who  may  yet  articulate  why 
that  is  a  bad  idea).  The  point  here  was,  the  emphasis  on  object-oriented  technology  is 
because  it  solves  real  software  engineering  problems;  it’s  not  just  a  technology  fad. 

The  second  thing  was  that  we  try  to  enumerate  some  of  the  things  where  we  felt  that, 
even  if  you  didn’t  come  up  with  a  grand  aggregate  strategy  structure,  it  would  be  useful  to 
search  for  mechanisms  for  commonality.  Those  included:  the  schema,  definitions  of  types 
and  methods  (with  possible  concern  of  granularity),  versioning,  transactioiis,  distribution, 
data  security,  multiple  use,  multiple  schema,  multiple  inheritance.  All  of  those  things 
were  areas  where  it  was  felt  there  was  some  real  work  on  addressing  commonality  that 
would  be  fruitful. 

Then  there  is  a  sort  of  statement.  (This  list  includes  statements  of  fact  about  the  universe, 
as  well  as  things  we  came  to  agreement  about.)  One  is  that  it  became  clear  in  this  discus¬ 
sion,  which  it  was  not  before,  that  of  the  two  specs,  one  defining  PCTE  and  one  defining 
the  ATIS,  ATIS  was  in  a  much  earlier  stage  of  its  evolution  and  was  therefore  more 
malleable  and  also  more  incomplete.  The  fourth  agreement,  that  we  just  discussed,  is  the 
relationship  between  the  PCIS  activity  and  the  evolution  of  PCTE.  Related  to  these  two 
things,  you’ll  see  some  actions. 

One  of  the  observations  that  was  made  was  that  there  really  is  no  place  in  the  standards 
activities  community  for  addressing  real  framework  issues:  there’s  no  home.  The  sixth 
agreement  is  about  the  commonality  of  schema  or  types  and  methods,  which  are  viewed 
as  important,  very  hard  to  achieve,  and  very  important  for  STARS  to  begin  addressing. 
The  seventh  agreement  is  that  STARS  should  be  working  to  assure  that  the  kind  of  diver¬ 
gence  that  was  perceived  in  the  past  doesn’t  get  exaggerated  in  the  process  we  go  through; 
at  the  very  least,  convergence  inhibiting  further  diversions  ought  to  be  an  objective.  (I 
think  it  was  a  much  stronger  actual  agreement.) 

The  last  two  points  of  agreement  were,  in  fact,  in  partial  dispute:  however,  it  was  asserted 
that  (in  ATIS)  you  could  separate  the  class  hierarchy  issue  from  the  dispatch  mechanism 
issue;  that  was  there  was  value  in  doing  that,  and  then  addressing  the  relationship 
between  the  dispatch  mechanism  [?in  both  systems?].  In  fact,  at  least  the  vendors  that 
were  here  who  are  making  investments  in  this  area  are  exploring  that  strategy. 

There  were  things  that  we  left  undecided,  at  least  two  of  which  we  have  just  gone  over 
that  are  not  on  this  list.  First,  it  was  not  decided,  in  the  exploration  of  this  commonality. 
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how  much  resolution  was  necessary  before  you  actually  gained  anything  in  terms  of  tool 
interoperability.  It  was  not  well  understood  by  this  group  (in  the  span  of  two  days)  how  far 
do  you  have  to  get  in  that  process.  There  were  really  radically  different  assumptions — 
Balzer’s  assumption  was  that  it  was  really  fruitful  to  explore  this  because  you  would  be 
getting  incremental  gains.  And  it  was  Ian  Thomas’  assumption  that  that  was  a  debatable 
issue;  it  was  not  clear. 

It  was  not  decided  whether  or  not  to  base  this  evolution  on  PCTE  and  view  it  as  a  matter 
of  value  added  [to  PCTE]. 

There  was  non-agreement  about  whether  it  was  appropriate  to  base  evolution  on  some 
version  of  UNIX,  for  example,  a  version  of  UNIX  on  which  ATIS  is  built  these  days. 


The  fourth  undecided  point  is  an  example  of  what  the  Object  Management  Group  is  doing 
in  various  exercises:  Andy  Rudmik  several  times  suggested  that  it  would  be  very  fruitful 
to  look  at  the  successes  in  those  communities  with  regard  to  interoperability,  to  see  if 
there  was  anything  to  be  learned  from  this  arena.  I  think  the  fact  that  there  was  no  agree¬ 
ment  on  this  is  more  a  reflection  of  the  fact  that  we  never  really  discussed  it  rather  than 
there  was  some  intrinsic  source  of  disagreement. 

We  never  discussed  or  agreed  upon  this  issue  of  monolithic  versus  partitionable  stan¬ 
dards,  and  we  never  really  got  beyond  this  sort  of  enumeration  of  strategic  goals.  We 
never  refined  that,  other  than  to  define  actions  that  could  be  taken  to  address  these  agree¬ 
ments  or  disagreements. 

The  actions  that  we  could  agree:  the  first  point  says  it’s  a  good  idea  and  STARS  should  be 
involved  in  it.  The  second  one  says  that  there  is  some  work  to  be  done  in  regard  to  the 
unresolved  issues,  and  some  activity  ought  to  be  engaged  to  do  that. 

Action  3,  the  commonality  search,  amounted  to  a  discussion  that  some  work,  on  the  order 
of  the  Waltham/Winnersh  exercise  that  was  done  for  CAIS/PCTE  convergence,  ought  to 
be  done  for  this  convergence  as  well.  This  isn’t  a  very  refined  suggestion  with  regard  to 
which  commonality  issues  need  that  kind  of  treatment.  Re  Note  1:  I  thought  that  we 
started  that  process  at  this  meeting,  but  Tricia  thought  that  the  start  was  pretty  darn  small 
compared  with  what  was  necessary.  Re  Note  2:  Bill  said  there’s  an  urgency  to  this  particu¬ 
lar  item:  that  something  must  get  resolved  before  the  June  meeting,  so  you  don’t  walk  into 
the  June  meeting  sending  the  wrong  signals  to  the  vendors. 


( 
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This  point  [Action  4]  addresses  the  issue  of  the  fact  that  there’s  no  home  in  the  standards 
world  for  frameworks.  Tricia  mentioned  that  people  are  beginning  to  suggest  homes  that 
^  probably  are  inappropriate  in  structure  of  the  standards  community  and  that  something 

may  be  done  about  this.  It  may  be  that  the  standards  community  is  susceptible  to  some 
actions  that  would  probably  be  appropriate  to  take. 

I  Action  5,  re  Agreement  7,  says  that  if  the  PCTE  and  AXIS  communities  are  really 

separate,  STARS  should  be  exercising  some  influence  in  these  communities. 

Action  6  addresses  the  issue  of  who’s  going  to  benefit  by  convergence;  how  should  that 
benefit  be  exploited  and  used  to  guide  the  activity?  As  an  example:  the  Unisys  commer- 
^  cial  people  came  with  information  about  a  strategy  for  doing  that,  and  it  became  clear 

that  there  was  an  interaction  between  the  Process  work  and  the  Environment  work  in  this 
area.  That  potential  interaction  would  be  very  beneficial  if  it  were  exploited  and  that  was 
suggested. 

Action  7  is  specifically  related  to  defining  and  exploiting  the  potential  interaction  with  the 
PCIS  process. 

Teri,  do  you  have  any  comments  or  questions?  I  think  we  had  a  very  good  discussion  and 
information  exchange.  People’s  positions  became  much  clearer  and  bases  for  their  posi¬ 
tions  became  much  clearer.  It  generated  a  lot  of  ideas.  We  didn’t  do  too  much  evaluating 
of  these  ideas  and  resolving  them  to  concrete  courses  of  action.  Here’s  the  territory,  figure 
out  what  to  do  about  them. 

I 

This  is  a  very  important  slide  [pointing  to  DG2]:  I  had  it  aside  to  pull  it  out  and  present  it 
tonight,  but  I  forgot. 


PROJECT  MODEL: 


—  Info  Model 


Proposals 


(Foil  drawn  by  D.  Goiffon) 


I  think  that’s  the  most  important  conclusion.  An  interesting  additional  conclusion  is  that 
as  Unisys  did  this,  one  of  their  conclusions  was  they  couldn’t  figure  out  how  to  define 
something  like  this  that  would  adequately  be  supported  by  PCTE  as  it  stands  or  by  AXIS 
as  it  stands. 

[discussion  by  David  Goiffon  of  Unisys] 

One  of  the  issues  that  came  up  was  whether  the  timing  of  the  activities  was  sufficiently 
synchronized  so  that  you  could  achieve  what  you’d  like  here.  But  it  also  may  be  true  here 
that  there  are  ways  that  subactivities  can  feed  both  into  the  Process  work  and  the 
Environment  work  independently  and  synergize  both.  To  assume,  for  example,  that  this 
information  has  to  go  through  the  Process  group  in  order  to  have  an  impact  on  the 
Environment  activity  is  inappropriate,  I  think. 


OK,  so  that’s  the  end. 
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APPENDIX  D 


MINUTES  OF  THE  CONVERGENCE  MEETING 


These  minutes  were  taken  by  Herman  Fischer,  and  were  edited  by  David  Carney. 


1.  JOURNAL  OF  DAY  1,  22  Jan  1991 

1.1  Welcome 


Jack  Kramer,  director  of  the  STARS  Program,  gave  a  brief  welcome  to  the  parti¬ 
cipants.  He  particularly  noted  that  Barry  Boehm,  director  of  DARPA’s  ISTO  Program, 
was  very  enthusiastic  about  the  potential  success  of  the  meeting.  Kramer  noted  that 
DARPA  considers  this  meeting,  and  frameworks  convergence  in  general,  an  important 
activity.  Kramer  pointed  out  the  need  in  the  STARS  program  for  open  architectures, 
standardized  frameworks,  and  widespread  commercial  solutions  for  common  Software 
Engineering  Environment  problems.  He  stated  a  need  to  be  able  to  buy  frameworks  “off 
the  shelf.”  Further,  the  STARS  program  will  need  to  decide  its  chosen  directions  for 
open  architecture  and  frameworks  within  the  next  nine  months. 


Kramer  noted  that  the  group  represented  a  wide  diversity  of  interests  and  investments.  It 
may  be  that  the  search  for  Frameworks  Convergence  will  begin  as  an  academic  exercise; 
but  it  will  soon  become  important  to  address  it  as  a  wider  problem  for  software  engineer¬ 
ing  in  general:  how  do  we  compose  tools  as  opposed  to  merely  invoking  them. 

Kramer  also  noted  the  current  progress  of  PCTE  in  becoming  an  accredited  standard.  He 
felt  that  this  represents  a  significant  event,  though  he  also  noted  how  long  it  has  taken  to 
arrive  at  this  point.  He  then  summarized  his  particular  concern,  and  the  major  point  (for 
STARS)  of  the  meeting.  If  one  compares  an  Entity-Relational  model  (such  as  PCTE  or 
CAIS-A),  with  an  Object-Oriented  one  (such  as  ATIS),  there  are  obvious  differences 
between  them,  and  between  the  commercial  forces  that  are  working  with  them.  If  these 
two  models  evolve  or  progress  in  divergent  directions,  this  could  be  catastrophic  for  any 
DoD  hopes  for  standardized  commercial  frameworks  and  environments. 

1.2  Capsule  Presentations 


Belz  then  requested  that  some  of  the  participants  present  capsule  overviews  of 
some  representative  programs  in  the  Frameworks  arena. 

Presenters: 

•  Regis  Minot,  PCTE,  Emeraude,  ECMA 

•  Herm  Fischer,  PCTE,  EAST,  Emeraude,  Sematech 

•  Gary  Pritchett,  CAIS-A  Program  Status 

•  Currie  Colket,  Brief  comments  on  PCIS 
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•  Tricia  Oberndorf,  NCGR/PSESWG 


Two  other  participants  also  gave  brief  presentations.  Andy  Rudmik,  of  the  CIS  Consor¬ 
tium,  commented  on  several  items  needed  for  systems  engineering:  class  models  (e.g., 
what  CIS  is  developing),  declarative  models,  and  system  administration  of  tailoring  and 
integrating  functions.  He  also  addressed  the  fact  that  technologies  to  support  process 
modeling  are  weak. 


Hugh  Beyer  gave  an  overview  of  ATIS: 

AXIS  is  a  [proposed]  standard  based  on  the  Atherton  Backplane,  with  UNIX  dependen¬ 
cies  removed.  The  document  is  a  proposed  base  standard  for  IRDS-2.  The  goal  {of 
ATIS]  is  to  have  the  repository  cover  the  entire  life  cycle  from  enterprise  modeling,  con¬ 
ceptual  modeling,  process  modeling,  application  design,  project  management,  mainte¬ 
nance,  reengineering,  etc.  ATIS  models  can  describe:  (a)  base  objects,  (b)  versioning, 
(c)  configuration  management,  (d)  tool  integration,  (e)  work  flow  control  (where  you  are 
in  the  life  cycle  in  a  process),  (f)  IRDS  concepts. 

Beyer  feels  that  the  Repository  has  to  be  Object-Oriented.  He  described  the  DEC  facility 
in  Varese,  Italy,  which  is  a  PCTE  site,  and  which  has  been  investigating  a  merger  of 
PCTE  and  ATIS.  They  built  an  underlying  0-0  object  base,  then  built  ATIS  and  PCTE 
on  top  so  that  constraints  were  implemented  by  methods.  PCTE  stability  links  were  used 
to  build  ATIS  constraints.  There  were  still  cases  where  the  PCTE  side  users  could  see 
more  than  the  ATIS  side  users  could.  The  experiment  proved  that  PCTE  and  ATIS 
could  share  the  same  object  base.  Beyer  noted  that  they  weren’t  addressing  schema-level 
mergers. 

Other  points  of  Beyer’s  presentation: 

—  DEC  has  produced  a  comparison  of  standards  using  ATIS  as  a  reference 
model 

—  ATIS  represents  RELATION  as  a  specific  type,  which  allows  PDES  to 
represent  relationships  directly  in  ATIS  models  (Beyer  noted  that  this  is  a 
controversial  topic  in  CIS). 


Frank  Belz: 


We’ve  completed  a  review  of  the  framework  initiatives  which  are  available  to  converge. 
Next  we’ll  look  at  alternate  solutions  and  see  how  they  might  be  complementary  or  con¬ 
flicting,  followed  by  technical  approaches  to  convergence.  We  will  then  try  to  identify 
technical  resolutions  on  achieving  convergence. 


One  problem  is  that  many  organizations  are  solving  the  problem  in  almost  the  same  con¬ 
text:  PCTE,  EIS,  CAIS,  et  al.  Because  of  the  different  people  involved,  you  get  dif¬ 
ferent  solutions  (which  first  look  like  design  inconsistencies).  STARS’  dilemma  is  to 
identify  whether  there  is  an  issue  of  CAIS  vs  PCTE  vs  ATIS,  or  whether  there  is  techni¬ 
cal  territory  where  these  do  not  differ. 

We  will  address: 

a.  merging  standards  (at  the  interface  level,  at  the  schema  level) 

b.  synergistic  coexistence  (of  existing  standards) 


Beyer:  Regarding  a  PCTE  and  ATIS  merger:  You  do  not  want  an  0-0  interface  on  top 
and  PCTE  below.  In  such  a  situation  [when  DEC  tried  it],  PCTE  ignored  the  constraints 
in  the  semantics  of  the  0-0  database.  Instead,  you  want  to  share  the  useful  part  of  the 
framework.  IBM,  DEC,  Pansophic  have  taken  approach  of  using  standard  database 
below  0-0,  and  eliminating  access  to  the  lower  level  database. 

DEC  did  build  an  underlying  0-0  object  base  (understanding  methods  and  objects),  and 
then  on  top  of  that  built  an  ECMA  PCTE  object  base  and  some  of  the  ATIS  interfaces. 
When  you  dispatch  a  method  or  define  an  object  on  the  ATIS  side,  it  turns  into  a  method 
dispatch  in  the  underlying  object  system.  All  the  semantics  are  in  the  shared  part  (the 
underlying  object  base).  PCTE  is  not  exclusively  object-oriented,  so  its  operations  need 
to  be  translated  into  ‘  uivalent  object  method  dispatches  (e.g.,  get  state,  return  this  link 
property,  etc.).  You  ud  up  with  one  unified  schema:  you  have  two  interfaces  to  same 
object  base,  but  different  versioning  models,  etc,  that  need  to  be  unified. 


Fischer:  noted  that  a  tool-level  schema  would  have  to  be  specificeilly  implemented  on 
both  the  ATIS  and  PCTE  sides  to  be  convertible,  so  that  they  could  have  this  translation. 

Thomas:  ATIS  defines  some  object  types  and  methods,  PCTE  also  defines  object  types. 
But  what  is  the  relationship  between  objects?  If  it  is  disjoint,  you  can’t  use  tools  on  both 
sides  predictably.  You  could,  however,  map  both  sides  to  a  simpler  underlying  set. 
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Beyer:  DEC  extended  [PCTE’s]  Schema  Definition  Sets  to  include  specifying  methods  on 
PCTE’s  side. 

Rudmik:  Questioned  whether  you  could  define  classes  in  a  bottom  layer  which  could  spe¬ 
cialize  to  AXIS  and  be  common  to  PCTE.  K  the  classes  for  the  two  are  substantially 
divergent,  the  models  are  different. 

Beyer:  Many  potential  users  want  common  type  definitions,  and  then  you  can  model  both 
frameworks  together. 

Balzer:  The  question  is  on  how  much  agreement  is  there  on  the  things  in  the  ’•epository 
and  in  the  support  structure.  How  critical  are  the  adopted  versioning  models? 

Fischer:  If  you  don’t  agree  on  the  versioning  model,  you  may  agree  on  tool  level  schema. 
[But]  the  set  of  assumptions  on  the  data  have  to  be  weaker. 

Kramer:  Got  “a  knot  in  stomach”  for  this  reason:  CAIS  decided  NOT  to  discuss  the  par¬ 
ticulars  of  configuration  management.  Making  decisions  on  a  particular  order  gives  pro¬ 
cess  decisions;  the  environment  should  have  flexibility  in  this  area  precisely  to  avoid 
“one  versioning  model.” 

Belz:  The  mechanism  of  how  tool-constructing  fiinctionality  is  given  may  be  incompatible 
(discussion  after  class  type  hierarchy  order). 

Balzer:  We’ve  had  one  proposal  for  convergence  (the  DEC  approach)  based  on  translat¬ 
ing  interfaces.  That’s  a  feasible  approach  at  the  interface  level.  What’s  important  is: 
what  else  do  you  need  for  interoperability  to  make  sense  (shared  schema,  etc)?  We  need 
a  synergistic  coexistence  (like  an  underlying  OODB).  Why  shouldn’t  it  be  possible  to 
take  a  PCTE  schema,  augmented  with  methods  on  it,  or  an  ATTS,  and  state  declaratively 
things  already  true  but  implicit?  This  doesn’t  change  tools,  but  changes  the  information 
already  known  by  any  tool  looking  at  Metadata  (schema).  Both  ATIS  and  PCTE  felt 
walking  the  data  structures  is  important;  but  adding  declarative  specifications  is  not 
incompatible  existence.  The  issue  is  that  there  is  an  opportunity  to  merge  the  advantages 
of  the  two  approaches. 

Fischer:  Suggests  adding  time-based  constraints. 

Balzer:  That  wo  rid  be  on  the  fringe  of  what  we  could  do. 
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Kramer:  Reflects  a  fear  of  0-0  items:  the  ability  to  see  “inside”  the  methods  in  an  easily 
communicated  way.  0-0  approaches  fall  back  into  trap  of  needing  to  see  inside  code. 

Fischer:  Noted  that  you  need  the  source  code  of  superclasses  to  see  how  they  behave  at 
lower  levels. 

1.3  Brainstorming  Session 

In  order  to  draw  forth  a  list  of  key  issues,  Belz  then  suggested  using  a  structured 
method  of  “brainstorming”.  The  technique  had  the  following  rules:  first,  each  participant 
would  have  the  opportunity  to  state  any  chosen  critical  issue.  The  issue  would  be 
recorded  without  debate,  and  there  was  no  limit  on  the  number  of  issues  that  any  indivi¬ 
dual  wished  to  raise.  Following  the  issue-raising  period,  there  would  be  a  structured  vote 
on  the  total  list  of  issues.  The  intention  was  to  isolate  the  items  or  areas  that  were  of  gen¬ 
eral  concern.  Oberndorf  noted  that  since  the  technique  permitted  issues  to  be  of  any 
scope,  the  voting  would  very  likely  require  “comparing  apples  and  oranges.”  Belz  replied 
that  this  was,  in  fact,  not  a  bad  thing:  the  nature  of  the  problem  was  such  that  such  com¬ 
parisons  were  often  necessaiy 

The  following  list  is  a  reproduction  of  the  items  as  they  were  recorded  during  the  brain¬ 
storming  session. 

1 .  Design  single  common  superset  of  systems. 

2.  Need  independent  standards  organization  to  drive  convergence. 

3.  Need  to  develop  independent  common  external  form  (how  we  exchange  data  with 
environments  through  neutral  form). 

4.  Include  schema  definition  in  the  process  of  convergence. 

5.  Fundamental  difference  in  paradigms  (00  vs  ER)  mean  that  we  have  to  investigate 
interoperability  mechanisms. 

6.  Still  do-able  to  find  common  schema  for  these  two  systems. 

7.  Given  that  PCTE  is  standardized  and  ATIS  needs  lots  added,  given  PCTE  interface, 
come  up  with  new  00  view  from  scratch  with  PCTE  in  mind  (instead  of  00  view 
with  UNIX  in  mind  like  CIS  is). 

8.  Framework  convergence  has  a  market  for  toolwriters,  and  that's  all;  tool  users  don 't 
care  about  framework  convergence.  Marketplace  is  toolwriters.  (Frank  wrote  down: 
exploit  the  fact  that  tool-writers  (not  users)  are  the  marketplace  for  (beneficiaries  of) 
convergence.) 

9.  We  should  converge  frameworks  by  defining  the  useful  union  of  CAIS,  PCTE, 
ATIS,  and  any  other  frameworks  we  find.  Jack  defined  useful  union  by  taking  the 
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10. 

11. 


12. 


13. 

14. 


15. 


16. 

17. 

18. 


19. 

20. 


21. 

22. 

23. 


24. 

25. 


intersection  (Venn  diagram)  and  adding  in  rest  of  features. 

Real  value  of  technology  is  ???  should  do  more  to  exploit  what  we  are  trying  to 
accomplish.  (Frank  wrote:  Exploit  the  fact  that  tool-users  are  the  marketplace  for 
(beneficiaries  of)  convergence.) 

Worried  about  giant  big  frameworks  we  can’t  implement.  Go  back  to  UNIX  file  sys¬ 
tem  and  add  to  it  the  things  we  need  to  achieve  our  goals.  Type  structure,  multi¬ 
inheritance,  object  orientation.  Wants  minimum,  smallest  system. 

Goal  should  be  single  standard,  not  two  standards  with  side  doors  for  tools  to  go 
through.  Superset  system  should  not  have  sub-standards. 

Design  as  a  common  service  on  top  of  ECMA  PCTE  an  00  layer  satisfying  object 
oriented  requirements  identified  for  these  systems  (in  particular  ATIS  and  PCIS). 
We’re  all  here  as  providers  [of  tools]  and  are  qualified  to  define  software  project  cul¬ 
tures  and  derive  qualitative  requirements  illustrating  the  end  usage  of  what  we  are 
trying  to  standardize. 

(Similar  to  7  &  13)  develop  OOISS  (Object-Oriented  Interface  Support  Services)  on 
top  of  PCTE  which  (a)  complements  PCTE  and  (b)  has  no  unnecessary  changes  to 
ATIS. 

Don’t,  [sic] 

Identify  the  layerings  of  our  environments.  Don ’t  develop  one  monolithic  standard. 
Call  the  bluff  of  the  ATIS  people  who  say  they  see  a  converging  path;  lay  out  the 
technical  steps  necessary  and  see  if  that  is  feasible.  Explore  the  proposed  “dual 
interface”  to  an  underlying  implementation  for  PCTE  and  ATIS  (Hugh’s  model)  in 
terms  of  the  technical  areas  that  it  must  address  to  determine  feasibility. 

Identify  a  common  acceptable  reference  model  for  verification  and  implementation 
of  the  framework  convergence. 

Standardize  disagreement.  Take  advantage  of  cases  where  we  can  agree  on  an 
approach  but  can’t  agree  that  it’s  worth  pursuing.  For  example,  ATIS  doesn’t  have 
mult  inheritance;  say  ”  if  you  were  doing  multi  inher.  you  would  do  it  this  way”. 
Corollary  to  8.  Exploit  concept  that  ultimate  benefactors  of  converged  environment 
are  application  developers. 

Target  convergence  in  the  software  engineering  workproduct  and  process  models 
Design  as  a  common  service  on  top  of  CAIS-A  an  OO  layer  satisfying  object 
oriented  requirements  identified  for  these  systems  (in  particular  ATIS  and  PCIS). 
Assure  that  framework  be  useful  for  small  as  well  as  large  systems  (for  example 
MCCR  applications  and  AIS  products). 

Take  PCTE  and  ATIS,  break  them  into  component  parts  or  layers,  before  we  con¬ 
sider  merging.  Then  we  take  the  pieces  and  shuffle  them  into  the  converged  output 
product. 
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26.  Define  levels  of  framework  extensions:  minimum  subset,  superset,  and  extensions  in 
between. 

27.  Include  ATIS  in  a  detailed  comparison  in  the  style  of  the  Winnerish  Report. 

28.  Drive  convergence  with  assumption  that  we  will  have  heterogeneous  frameworks  for 
a  while  (assumes  they  have  to  interoperate). 

29.  Build  supersets  of  existing  standards.  Start  with  merging  of  declarative,  ER,  and 
imperative  00  models. 

30.  Allow  incompatible  extensions  to  the  various  input  standards  when  we  do  the  con¬ 
vergence. 

31.  Define  the  timeframe  within  which  we  expect  results. 

32.  Framework  must  be  elegant,  simple,  affordable,  efficient,  and  commercially  mark¬ 
etable.  Define  market  size  before  designing. 

33.  Take  advantage  by  leveraging  existing  standards  such  as  OSF,  SQL,  Motif,  X  Win¬ 
dows. 

34.  Framework  is  more  than  the  object  manager.  Should  have  an  object  manager  which 
defines  as  objects  all  the  things  of  the  framework,  (widgets,  windows,  etc).  To  han¬ 
dle  complexity  you ’d  need  subschema. 

35.  You  should  encourage  tools  to  go  back  to  the  UNIX  ‘‘small  is  beautiful”  religion;  a 
tool  should  do  one  job.  A  tool  should  not  do  internal  versioning,  transactions,  and 
other  things  which  other  tools  do. 

36.  Support  migration  and  encapsulation  of  existing  tools. 

37.  Understand  if  and  how  OODB  vendors  have  a  place  in  this  brave  new  world. 

38.  Define  the  role  that  the  PC  will  play  in  the  frameworks  of  the  future  (including  Next 
and  super-PCs  which  will  be  almost  in  the  home). 

39.  Attach  high  priority  to  the  distribution  architecture  requirements. 

40.  Design  to  accomodate  multiple  changing  underlying  OSes  and  comparable  services. 

41.  Be  able  to  encapsulate  different  frameworks. 

42.  Encapsulate  toolsets  (in  addition  to  individual  tools). 

43.  Lowest  level  of  standard  should  be  an  OO  NFS. 

44.  Don ’t  feel  compelled  to  take  various  standards  in  entirety  but  take  meaningful  neces¬ 
sary  subset. 

45.  Defer  distribution  architecture  to  lower  level  services. 

The  list  was  then  examined  in  two  ways.  First,  the  issues  were  discussed  to  see  if  any  gen¬ 
eral  categories  emerged.  The  following  categories  were  suggested: 

•  Framework  Requirements 

•  Standards  (including  supersetting  and  subsetting  strategies) 

•  Framework  Standards  Development:  Technical  approach 
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•  Target  Markets 

•  Framework  Standards  Development:  Management  approach 

NB:  As  the  issues  were  categorized,  the  participants  noted  that  these  categories  were  not 
a  true  partition  of  the  issues,  and  thus  that  it  was  possible  for  an  issue  to  be  a  member  of 
more  than  one  category. 

Following  this  step,  issues  that  were  deemed  to  be  similar  were  aggregated.  The  degree  of 
similarity  was  variable,  but  some  collapse  of  the  large  list  was  felt  to  be  necessary.  (In 
fact,  one  of  the  aggregations  collapsed  statements  that  were  precisely  contradictory.  The 
rationale  for  this  was  that,  whether  one  chose  the  negative  or  positive  view,  the  state¬ 
ments  referred  to  the  same  issue.) 

The  following  table  lists  the  issues  in  the  chosen  categories. 


Category  Issue  number 


Topic 


Framework  Requirements: 


Common  External  Form 
{aggregated  as}  Common  Schema 
Back  to  Unix 
Goal  is  a  single  standard 
Identify  layering  of  environments 
Identify  common  Reference  Model 
Goal  is  small  as  well  as  large  systems 
Assume  heterogeneous  frameworks 
Goal  is  elegance,  simplicity,... 

Leverage  existing  standards 

Define  Framework  as  more  than  Object  Manager 

Small  is  beautiful 

Support  tool  migration  and  encapsulation 
Define  role  of  PC 

High  priority  to  distribution  requirements 
Design  to  accomodate  underlying  change 
Design  to  encapsulate  different  frameworks 
Encapsulate  toolsets 
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43 

44 

45 


Lowest  level  should  be  an  0-0  NFS 
Take  meaningful  subset  of  standards 
Defer  distribution  architecture  issue 


Standards  (including  supersetting  and  subsetting  strategies): 


1  Design  single  common  superset 

26  Define  framework  extensions 


Framework  Standards  Development  (Technical  Approach): 


5 

4,6 

7,13,15 

9,44 

11 

18 

20 

23 

25 

27 

29 

30 
43 


Investigate  interoperability  mechanisms 
{aggregated  as}  Common  Schema 

{aggregated  as}  0-0  on  top  of  PCTE  ® 

{aggregated  as}  Useful  union  of  CAIS,PCTE,  and  ATIS 
Back  to  Unix 

Common  interface  below  PCTE  and  ATIS 

Standardize  disagreement  • 

Design  0-0  layer  on  top  of  C AIS-A 

Restart  from  ATIS  and  PCTE  components 

Need  for  a  Winnersh-style  ATIS  report 

Build  supersets  from  existing  standards 

Allow  incompatible  extensions  ® 

Lowest  level  should  be  an  0-0  NFS 
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Target  Markets: 


8,10,14,21,37  Know  the  market/users  of  frameworks 


Framework  Standards  Development  (Management  Approach): 


2  Standards  organizations  drive  convergence 

14  Who  are  we  trying  to  satisfy 

16  Don’t 

22  Focus  on  workproduct  and  process  models 

31  Define  convergence  timeframe 

33  Leverage  existing  standards 


2.  JOURNAL  OF  DAY  2,  23  Jan  1991 

2.1  Summary  Presentation:  Bob  Balzer 

At  the  start  of  the  second  day,  Balzer  gave  a  summary  presentation  on  possible 
ways  to  foster  convergence.  One  key  question  is:  What  do  we  mean  by  convergence? 
Balzer  suggested  some  possible  answers.  Convergence  might  mean: 

•  a  single  standard 

•  interoperability,  where  each  operates  in  its  own  context,  but  dynamically 
shares  data  (interactions  between  tool  and  framework  while  it  is  operating) 
(selectively  shared  semantics  where  tools  require  semantics  on  both) 

•  encapsulated  batch  execution  (foreign  tools  concept)  (can  spawn  ATIS  tool  in 
PCTE  and  import  its  data  when  done) 

•  reduced  porting  cost  (assume  multiple  frameworks  in  environment,  reduce  cost 
of  getting  same  tool  to  work  in  both  environments) 

During  the  following  discussion,  three  other  possible  meanings  for  convergence  were 
noted: 


•  independent,  but  compatible  standards  (cf.  the  discussion  of  ‘Profiling’).  This 
could  mean  subdividing  monolithic  standards  into  compatible  pieces,  thus  mak¬ 
ing  the  standards  ‘profitable’. 

•  extended  standards,  thus  reducing  the  distance  separating  them 

•  complementary  standards 

Kramer:  Wants  an  idea  of  what  directions  STARS  can  consider  by  end  of  the  day.  Jack 
wants  the  group  to  clarify  the  appropriate  goals  for  STARS,  and  the  appropriate  steps 
STARS  should  take.  What  are  the  criteria  (technical  8c  pragmatic)  by  which  STARS  will 
make  its  selection? 

2.2  Profiling  Of  Standards 

Oberndorf  gave  a  brief  presentation  on  ‘profiling’,  as  defined  in  other  similar 
activities  such  as  the  POSDC  “.0”  group.  One  key  notion  in  such  activities  is  organizing  a 


higher  level  issue  of  profiles,  which  is,  essentially,  picking  a  thread  of  capabilities  from  a 
set  of  standards.  Said  differently,  a  profile  is  a  way  of  relating  a  set  of  standards  aggre¬ 
gated  together.  Thus,  an  aggregate  of  standards  for  an  OS,  networking,  data  mangement, 
and  data  interchange  definitions  of  a  computer-based  information  system  would  be  a  pro¬ 
file. 

As  an  example:  assume  one  is  putting  together  a  specification  for  some  system.  Key  ques¬ 
tions  might  be:  is  it  distributed  or  not;  is  it  a  banking  system;  does  it  need  this  special 
capability  which  has  no  standard  yet;  (e.g.,  for  every  capability  you  need  a  standard,  is 
there  one  which  matches);  etc. 

STARS  is  seeking  a  category  of  profiles,  a  world  of  technological  capabilities.  One  criti¬ 
cal  issue  is  that,  when  looking  at  suites  of  standards,  one  can’t  pick  two  simply  off  the 
shelf  because  they  may  have  underlying  incompatiblities. 


Thomas:  Gave  a  picture  of  standards  selection  with  OSI  protocol  stack,  3  at  top  layer,  2 
next  layer  down,  2  bottom  layer.  Given  that  picking  any  choice  at  one  level  implies  con¬ 
straints  at  the  lower  levels,  then  with  ATIS  and  PCTE,  if  you  have  object  managers,  pro¬ 
cess  managers,  etc.,  it  is  extremely  hard  to  identify  the  lower  chunks  and  determine  the 
constraints  to  take  lower  chunks  and  mix  and  match  from  PCTE  and  ATTS. 

Fischer:  Note  that  the  sub-chunks  of  ATIS  and  PCTE  are  all  highly  cohesive  and  not 
separable,  and  couldn’t  be  recombined. 

Kramer:  Note  that  reworking  a  tool  from  ATIS  to  PCTE  involved  reworking  interfaces 
(easy),  data  models  (harder),  and  control  models  (impossible). 

Balzer:  spoke  of  ‘Dual  Interfaces:’  The  Varese  DEC  model  dispatched  methods  under 
PCTE  to  use  the  same  OODB  as  ATIS.  Concerns  not  addressed  are: 

(1)  Shared  schema  (or  highly  inter-mappable) 

(2)  Shared  meta  model 

(a)  Transactions 

(b)  Versioning 

(c)  Security 

You  could  then  add  PCTE  semantics  to  the  line  between  the  ATIS  implementation  layer 
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and  the  underlying  OODB  layer.  Alternatively  you  could  reimplement  what  DEC  did  at 
Varese  and  implement  AXIS  on  an  E-R  database  and  add  AXIS  semantics  to  the  line 
from  AXIS  to  the  ER  database. 

Kramer:  SXARS  needs  to  use  existing  commercially  supported  standards.  Xhe  SXARS 
Primes  could  use  different  choices  of  standards  as  long  as  there  was  a  possibility  of  merg¬ 
ing  or  migrating  the  standards  to  each  other.  SXARS  would  play  a  role  in  driving  this  con¬ 
vergence.  (Xhe  preferred  alternative  is  for  SXARS  to  select  a  single  standard.) 

2.3  Frank  Belz’s  Review  Of  The  Meeting 

Called  it  “Convergence  of  OUR  Process:”  First,  made  small  clarifications  of 
strategies/programs  were  helping  there,  and  that  the  SXARS  primes  were  working  with 
their  commercial  affiliates  to  do  the  same  thing.  From  the  SEI  process  work,  SXARS  will 
both  push  them  into  the  process  and  learn  from  what  they  are  doing. 

In  the  next  hour,  we  must  come  to  concurrence  about  what  we  have  concurrence  on. 

2.4  Voting  On  ‘Brainstorming’  Issues 

Votes  were  taken  on  the  “brainstorm  topics”  to  determine  the  most  important 
issues  in  the  topic  of  convergence.  Each  attendee  was  given  15  votes  to  distribute  among 
the  forty-four  issues.  Any  issue  could  receive  up  to  three  votes;  thus  each  participant 
would  need  to  vote  for  at  least  five  of  the  issues.  A  vote  for  any  member  of  an  aggregate 
issue  was  regarded  as  a  vote  for  the  entire  aggregate. 

Xhese  were  the  results: 
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Most  Significant  Topics 


Item  number(s) 


Topic 


Vote  Count 


7,13,15 

OO  on  top  of  PCTE 

37 

1,9,29,44 

Useful  Union 

28 

10,14,37 

Know  thy  users 

26 

• 

4,6 

Schema 

24 

17 

Layering  environments 

17 

18 

Common  I/F  below  AXIS  &  PCTE 

14 

13 

Standards  organizations  drive  convergence 

13 

• 

11 

Back  to  Unix 

12 

27 

Winerish-style  AXIS  report 

12 

28 

Heterogeneous  frameworks 

12 

32 

Boy-scout  motto 

11 

35 

Small  is  beautiful 

11 

3 

Restart  from  ATIS&PCTE  components 

11 

• 

25 

Independent  common  external  form 

10 

Remaining  Topics 

Item  Number 

Topic 

Vute  Count 

• 

5 

Investigate  interoperability  mechanisms 

8 

19 

Identify  common  Reference  Model 

8 

38 

Define  role  of  PC 

7 

23 

Design  OO  layer  on  CAIS-A 

6 

24 

Goal  is  small  as  well  as  large  systems 

6 

• 

26 

Define  framework  extensions 

6 

34 

Define  framework  as  more  than  object  manager 

6 

36 

Support  tool  migration  &  encapsulation 

6 

39 

High  priority  to  distribution  requirements 

4 

40 

Design  to  accomodate  underlying  change 

4 

12 

Goal  is  a  single  standard 

3 

• 

31 

Define  convergence  time&ame 

3 

30 

Allow  incompatible  extensions 

2 

33 

Leverage  existing  standards 

2 

43 

Lowest  level  should  be  OO  NFS 

2 

16 

Don’t 

1 

20 

Standardize  disagreement 

1 

• 

41 

Ability  to  encapsulate  different  frameworks 

0 

22 

Focus  on  workproduct  &  process  models 

0 

42 

Encapsulate  toolsets 

0 

The  following  tables  expand  these  results,  showing  the  exact  wording  of  all  aggregate 
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issues,  for  the  most  significant  items. 


OO  sur  PCTE  {7,13,15:  first  place  with  37  votes} 

1  Given  that  PCTE  is  standardized  and  ATIS  needs  lots  added,  given  PCTE  inter¬ 
face,  come  up  with  new  OO  view  from  scratch  with  PCTE  in  mind  (instead  of  OO 
view  with  UNIX  in  mind  like  CIS  is). 

13  Design  as  a  common  service  on  top  of  ECMA  PCTE  an  OO  layer  satisfying 
object  oriented  requirements  identified  for  these  systems  (in  particular  ATIS  and 
PCIS). 

15  Develop  OOISS  (Object  Oriented  Interface  Support  Services)  on  top  of  PCTE 
which  (a)  complements  PCTE  and  (b)  has  no  unnecessary  changes  to  ATIS. 

Useful  Union  {1,9,29,44:  second  place  with  28  votes} 

1  Design  single  common  superset  of  systems. 

9  We  should  converge  frameworks  by  defining  the  useful  union  of  CAIS,  PCTE, 
ATIS,  and  any  other  frameworks  we  find.  Jack  defined  useful  union  by  taking  the 
intersection  (Venn  diagram)  and  adding  in  rest  of  features. 

29  Build  supersets  of  existing  standards.  Start  with  merging  of  declarative,  ER,  and 
imperative  OO  models. 

44  Don’t  feel  compelled  to  take  various  standards  in  entirety  but  take  meaningful 
necessary  subset. 

Know  thy  users  {10,14,37:  third  place  with  26  votes} 

10  Real  value  of  technology  is  ???  should  do  more  to  exploit  what  we  are  trying  to 
accomplish.  (Frank  wrote:  Exploit  the  fact  that  tool-users  are  the  marketplace 
for  (beneficiaries  of)  convergence.) 

14  We’re  all  here  as  providers  [of  tools]  and  are  qualified  to  define  software  project 
cultures  and  derive  qualitative  requirements  illustrating  the  end  usage  of  what  we 
are  trying  to  standardize.  Resolve:  Who  are  we  trying  to  satisfy 

37  Understand  if  and  how  OO  DB  vendors  have  a  place  in  this  brave  new  world. 


Schema  {4,6:  fourth  place  with  24  votes} 


4  Include  schema  definition  in  the  process  of  convergence. 

6  Still  doable  to  find  common  schema  for  these  two  systems. 


Layering  environments  {4,6:  fifth  place  with  17  votes} 

17  Identify  the  layerings  of  our  environments.  Don’t  develop  one  monolithic  stan¬ 
dard. 

Common  Interface  below  AXIS  &  PCTE  (18:  sixth  place  with  14  votes) 

18  Call  the  bluff  of  the  ATIS  people  who  say  they  see  a  converging  path;  lay  out  the 
technical  steps  necessary  and  see  if  that  is  feasible.  Explore  the  proposed  “dual 
interface”  to  an  underlying  implementation  for  PCTE  and  AXIS  (Hugh’s  model) 
in  terms  of  the  technical  areas  that  it  must  address  to  determine  feasibility. 


OTHEH  ITEMS  FROM  THE  VOTING: 

Standards  organizations  drive  convergence. 
Back  to  UNIX. 


Include  AXIS  in  a  detailed  comparison  in  the  style  of  the  Winnerish  Report. 

Drive  convergence  with  assumption  that  we  will  have  heterogeneous  frameworks 
for  a  while  (assumes  they  have  to  interoperate). 

Framework  must  be  elegant,  simple,  affordable,  efficient,  and  commercially 
marketable.  Define  market  size  before  designing. 

You  should  encourage  tools  to  go  back  to  the  UNIX  “small  is  beautiful”  religion;  a 
tool  should  do  one  job.  A  tool  should  not  do  internal  versioning,  transactions,  and 
other  things  which  other  tools  do. 

Take  PCTE  and  AXIS,  break  them  into  component  parts  or  layers,  before  we  con¬ 
sider  merging.  Then  we  take  the  pieces  and  shuffle  them  into  the  converged  out¬ 
put  product. 
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Need  to  develop  independent  common  external  form  (how  we  exchange  data  with 
environments  through  neutral  form). 


APPENDIX  E 


DOCUMENTS  REFERENCED  AT  THE  MEETING 


Some  of  these  documents  were  distributed  either  before  or  during  the  meeting. 


1.  Contribution  by  Dr.  John  Nissen,  GEC  Marconi  Software. 

There  is  no  indication  on  this  document  of  its  date  or  source  of  publica¬ 
tion,  nor  the  nature  of  the  occasion  for  this  "contribution.  ”. 

2.  PCTE  -  AXIS  Common  Environment:  A/D.  Fabio  Bagatin,  SDT  Italy, 
NASHUA,  October  7, 1990. 

A  set  of  forty  briefing  slides.  The  reference  to  Nashua  is  a  reference  to 
DEC. 

3.  Object  Database  Management  Systems:  Concepts  and  Features.  Christopher  E. 
Dabrowski,  Elizabeth  N.  Fong,  and  Deyuan  Yang.  NIST  Special  Publication 
500-179,  April  1990. 

This  document  was  discussed  and  distributed  during  the  meeting  and 
was  incorrectly  assumed  to  be  a  Reference  Model  for  Object-Oriented 
environments. 

4.  A  Reference  Model  for  Computer  Assisted  Software  Engineering  Environment 
Frameworks.  Anthony  Earl,  Hewlett  Packard,  August  17, 1990. 

This  document  is  the  ECMA  Reference  Model,  which  has  also  been 
accepted  in  large  part  by  the  NIST  ISEE  Working  Group. 

5.  CASE  Integration  Service:  Technical  Description.  Chris  J.  Nolan,  Digital  Equip¬ 
ment  S.p.A.,  Varese,  Italy,  March  31, 1990. 

6.  Introduction  to  CAIS:  Common  Ada  Programming  Support  Enrironment  (APSE) 
Interface  Set  (MILrSTD-1838A).  C.  Hitchon  et.  al.,  September  30, 1989. 


7.  A  Comparison  Analysis  of  Repository  Approaches.  Hugh  R.  Beyer,  Kathy 
Chapman, and  Chris  Nolan.  September  17, 1990. 

8.  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS):  Task  BS25: 
Object  Manager  Technology  Framework  Specification  Comparison.  The  Boeing 
Company,  January  4, 1991. 


9.  Enterprise  II:  L’Environment  de  genie  logiciel.  November  26, 1990. 

This  paper  was  brought  by  Regis  Minot,  and  refers  to  an  environment 
constructed  using  a  basis  of  Emeraude  PCTE. 


10.  Emeraude:  A  Production  Quality  Implementation  of  PCTE.  GOB  Emeraude, 
1990. 

Two  sets  of  briefing  slides.  The  first  twenty  slides  are  particular  to  the 
Emeraude  implementation  of  PCTE;  the  remainder  of  the  slides  describe 
Enterprise  II  (cf.  #  10)  and  EAST. 


11.  Corrigienda  and  Addendum  to  Papers  for  International  Workshop  on  UNIX- 
Based  Software  Development  Environments.  Several  papers  by  various  authors. 
Numerous  papers  and  topics;  several  are  descriptions  of  aspects  of  the 
Japanese  SIGMA  project. 


V.  Comparison  of  CAIS-A  and  PCTE+  June  1988,  Ada  Joint  Program  Office,  U.S 
Department  of  Defense,  and  the  Independent  European  Programme  Group, 
Technical  Area  13. 

This  is  the  ‘"Waltham  Report”  that  examined  technical  differences 
between  CAIS-A  and  PCTE-\-,  both  of  which  are  ERA  interface  sets. 


1  ’.  PCTE+  and  CAIS-A  Convergence  November  1989,  Ada  Joint  Program  Office, 
U.S.  Department  of  Defense,  and  the  Independent  European  Programme 
Group,  Technical  Area  13. 

This  is  the  “Winnersh  Report”  that  concluded  that  convergence  between 
CAIS-A  and  PCTE+  was  feasible.  The  result  of  this  report  was  the  crea¬ 
tion  of  the  PCIS  initiative  which  is  currently  in  the  process  of  determin¬ 
ing  requirements. 
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